日期時間轉換器
在 Unix 時間戳、JavaScript 毫秒、ISO 8601、ISO 9075、RFC 3339、RFC 7231、Mongo ObjectID 與 Excel 序列號之間互相轉換，自動識別輸入格式。
把同一個時間點轉換成你需要的所有格式。
時間戳格式詳解
秒還是毫秒
處理時間戳時最常見的錯誤就是混淆這兩者。Unix 時間戳從 1970-01-01 UTC 起計秒，而 JavaScript 的 Date.now() 計的是毫秒。如果把 Unix 時間戳不乘 1000 直接丟進 Date 建構函式，結果會落在 1970 年 1 月。經驗法則是：10 位數是秒，13 位數是毫秒——本工具的自動識別正是這樣判斷的。
各種標準的區別
- ISO 8601 是基準標準：
2024-01-15T10:30:00.000Z。T分隔日期與時間，Z表示 UTC。 - RFC 3339 是面向網際網路協議的 ISO 8601 嚴格子集，要求顯式寫出時區偏移，所以用
+00:00而不是Z。 - ISO 9075 是 SQL 標準格式
2024-01-15 10:30:00——用空格代替T，且不帶時區。大多數資料庫輸出的就是這種。 - RFC 7231 是 HTTP 日期格式，用於
Date、Expires、Last-Modified響應頭，始終使用 GMT。
兩個特殊格式
Mongo ObjectID 共 12 位元組，前 4 位元組就是以 Unix 秒錶示的建立時間，因此每個 ObjectID 內部都自帶時間戳。本工具在解碼時會把它提取出來；在生成時則將剩餘 8 位元組補零，而不是偽造機器標識和計數器。
Excel 序列號表示自 1899-12-30 起的天數，小數部分代表當天的時刻。這個看似奇怪的起點，源於 Excel 刻意復現了 Lotus 1-2-3 把 1900 年當作閏年的歷史 bug。把 1899-12-30 當作第 0 天，可以讓 1900 年 3 月以後的所有日期都對得上，所以本工具採用這個基準。
本質上只是同一個瞬間
無論你輸入哪種格式，工具都會先解析成一個 JavaScript Date 物件，再把這同一個瞬間用全部 11 種格式重新渲染出來。所有轉換都在瀏覽器本地完成，資料不會上傳。
常見問題
為什麼我的 Unix 時間戳顯示成 1970 年？
幾乎可以肯定是把秒當成毫秒傳了。乘以 1000 即可，或者直接把輸入格式選為「Unix 秒」，讓工具替你處理。
ISO 8601 和 RFC 3339 有什麼區別？
RFC 3339 是面向網際網路協議的 ISO 8601 嚴格子集。所有 RFC 3339 日期都是合法的 ISO 8601，反之則不然——RFC 3339 必須寫出 +00:00 這樣的數字偏移，而 ISO 8601 還允許 Z、週日期和序數日期等寫法。
能從 Mongo ObjectID 裡取出時間嗎？
可以。ObjectID 的前 4 位元組（8 個十六進位制字元）就是以 Unix 秒錶示的建立時間。貼上 ObjectID，工具會把那個瞬間解碼成其餘所有格式。
為什麼 Excel 的起點是 1899-12-30 而不是 1900-01-01？
Excel 刻意保留了 Lotus 1-2-3 把 1900 年當作閏年的 bug。把起點前移到 1899-12-30 正好抵消由此產生的一天偏差，使 1900 年 3 月以後的日期都能正確換算。
我的資料會上傳到伺服器嗎？
不會。所有解析和格式化都在你的瀏覽器本地使用標準 Date API 完成，不上傳、不記錄。