Unix 時間戳：秒、毫秒和錯誤的日期
四個輸入，一個瞬間。了解為什麼時間戳會落在 1970 年或錯誤的日期。
落在 1970 年 1 月的時間戳，單位常常會搞錯。數字 1792069200 是 Unix 秒；1792069200000 是同一瞬間的毫秒。兩者都不需要在轉換前加上時區偏移。
開啟 時區轉換器，展開 貼上日期或時間戳，貼上任一數字並選擇 轉換。檢查表單下方的解讀結果。兩者都應該產生 2026-10-15T13:00:00.000Z。
同一時刻的四種寫法
逐一試試這些，或下載 四個時間戳範例：
1792069200
1792069200000
2026-10-15T13:00:00Z
2026-10-16T00:00:00+11:00
最後一行已經是隔天的午夜，但它仍然代表同一時刻。其明確的十一小時偏移說明了差異。
工具會將第一個數字讀為秒，第二個讀為毫秒。對於今天的日期，10 位數與 13 位數是實用的線索，但不是時間戳的通用定義。這個轉換器會拒絕 11 位和 12 位的數字輸入，而不是猜測。它支援 1900 年到 2100 年的日期；它不是所有歷史時間戳格式的解析器。
如果你在寫 JavaScript，數字 Date 建構子預期的是毫秒。MDN 的 Date 參考 記錄了該單位。將秒乘以 1,000 是單位換算，不是時區調整。
檢查日期，也要檢查時鐘
使用 新增時區 來加入你需要的城市。對於上述範例，測試結果如下：
| 時區 | 當地日期與時間 | 該日期的 UTC 偏移 |
|---|---|---|
| UTC | 2026 年 10 月 15 日 13:00 | +00:00 |
| Australia/Melbourne | 2026 年 10 月 16 日 00:00 | +11:00 |
| Europe/London | 2026 年 10 月 15 日 14:00 | +01:00 |
| America/New_York | 2026 年 10 月 15 日 09:00 | -04:00 |
這些偏移屬於範例日期。不要將它們重用為城市之間的永久差異；日光節約時間可能改變差距。對於重複性任務，請參閱 cron 與日光節約時間範例。
在任何時鐘卡片內拖曳會移動共享時刻，因此所有卡片會一起更新。複製所有時間 也會複製日期和偏移。這對隊友來說比只發送「9am」更有用。
沒有偏移的日期是另一種輸入
貼上 2026-10-15T13:00，並將 未指定時區時，按以下時區讀取 設為 Australia/Melbourne。它會變成 2026-10-15T02:00:00.000Z，比我們的第一個範例早十一小時。
沒有壞掉：這次你提供的是當地時鐘讀數，而來源時區提供了缺失的上下文。對於 Unix 數字或明確的偏移，該來源選擇不會移動瞬間。我的時區 可以加入你裝置的時區，但你的裝置無法告訴你未標籤的日誌條目原本使用哪個時區。
分享前先解決模糊輸入
工具會刻意要求你釐清幾種輸入：
10/11/2026 09:00可能指 10 月 11 日或 11 月 10 日。請使用年-月-日格式的日期。2026-10-15 09:00 CST使用模糊的縮寫。請選擇完整的來源時區或提供明確的 UTC 偏移。2026-11-01T01:30在America/New_York中，當時鐘往回撥時會出現兩次。請提供預期的偏移；單靠當地時鐘讀數無法在兩者之間選擇。
我們在 2026 年 10 月 15 日檢查了這些輸入和四個等效時間戳，對照工具的解析器。轉換輸出 和 結果記錄 保留了確切值。自然語言解析因語言而異；當時間必須明確時，明確的日期和偏移是更好的選擇。