ISO 8601 · RFC 3339

ISO 8601 轉換器
日期格式檢查

2024-01-01T09:00:00+09:00檢查帶有時區的日期,例如:它立即顯示格式是否正確,UTC 時間,以及 Unix 秒、毫秒、微秒和奈秒是什麼。

檢查和轉換 ISO 日期字串

Z 或 ±HH:mm 請輸入包括位移量。第二位以下最多保留 9 位數字。

驗證結果—
標準化 UTC 格式
—
輸入 UTC 位移量—
世界時間 UTC—
韓國標準時間 KST—
本機時間—
Unix 秒
—
Unix 毫秒
—
Unix 微秒
—
Unix 奈秒
—

輸入的日期字串僅在此頁面上進行檢查,不會傳輸或儲存。

有效的 ISO 8601 範例

該工具使用日期, T,採用包含小時、分鐘、秒和明確時區的格式。

輸入範例意義核對重點
2024-01-01T00:00:00Z00:00 世界協調時間Z是 +00:00
2024-01-01T09:00:00+09:00韓國上午9點與上面 0:00 UTC 相同的時刻
2024-01-01T00:00:00.123Z包括毫秒3 位小數
2024-01-01T00:00:00.123456789Z包括奈秒最多保留小數點後 9 位
2023-12-31T19:00:00-05:00比 UTC 晚 5 小時的地區2024-01-01 00:00 (UTC)

如果缺少時區,則無法確定單個時刻。 2024-01-01T12:00:00僅憑外表你無法判斷現在是韓國中午還是UTC中午。要共享或儲存的值包括: Z 或者添加數字位移量。

如何讀取 Z,+09:00,-00:00

末尾的標記描述了本地時鐘相對於 UTC 的領先或落後程度。

Z

Z 是世界協調時間

12:00:00ZUTC 時間為中午。字母 Z 偏移 +00:00意思是和一樣的時間。

+

+09:00 是韓國標準時間

顯示的時鐘比 UTC 早 9 小時。換算為 UTC 時,從顯示時間減去 9 小時。

?

-00:00 表示當地位移量未知

它在計算上與UTC相同,但這意味著我們不知道原始區域的位移量,所以 +00:00分開。

格式驗證失敗的常見原因

日期或時區資訊不明確時,即使字串外觀相似,也無法安全判斷是否為同一瞬間。

無時區

2024-01-01T12:00:00 不包含 Z 或 UTC 位移量,請補充時區後重新輸入。

不存在的日曆日期

2024-02-30T00:00:00Z 這類不存在的日期無法轉換。

空白格式

請在日期與時間之間使用大寫字母 T,不要寫成 2024-01-01 00:00:00。

檢查標準: 在網際網路上明確表達日期(包括時區)的規則是: RFC 3339您可以在這裡查看。如何以 UTC 格式表示 ISO 字串 MDN 的 ISO 字串指南您還可以參考:此工具僅接受指定時區的完整日期以避免歧義,並且包括閏秒。 60不會更改為常規 Unix 時間。

ISO 8601 常見問題解答

以下整理時區標記、位移量與小數秒的常見疑問。

ISO 8601 中的 Z 是什麼意思?

日期末尾的 Z 代表 UTC,或 +00:00 位移量。 2024-01-01T00:00:00Z 和 2024-01-01T00:00:00+00:00 指的是同一時刻。

加上 +09:00 就代表韓國標準時間嗎?

是的。 +09:00 表示時間比 UTC 早 9 小時。 2024-01-01T09:00:00+09:00 與 2024-01-01T00:00:00Z 是同一時刻。

沒有時區的 2024-01-01T12:00:00 可以轉換嗎?

為了避免誤解,此工具僅轉換必須具有位移量的格式,例如 Z 或 +09:00。如果沒有時區,同一個數字可以代表不同地區的不同時刻。

最多可驗證幾位小數?

秒後最多驗證 9 位小數,並以奈秒精度保留。例如 .123456789 會完整出現在正規化 UTC 格式與單位結果中。

-00:00 和 +00:00 意思一樣嗎?

兩者在數值上都對應 UTC,但語意不同:-00:00 表示當地位移量未知,因此本工具會單獨標示。