文章
ISO 8601時長:P1DT2H是什麼意思
YouTube API的回應裡,某支影片的時長寫作PT4M13S。行事曆邀請裡帶著P15DT5H0M20S這樣的值。某個目錄伺服器給帳號打上20260424174227.0Z這樣的時間戳記,看起來和前面那些有關聯,實際上卻完全是另一回事。這些簡潔的字串遵循著值得了解的規則,因為讀錯就會把分鐘變成月份。這篇文章帶你梳理ISO 8601時長格式:每個字母代表什麼、這種格式出現在哪裡,以及最需要留意的一點:按這種方式寫出的時長並不總是固定不變的時間量。
P、T,以及每個字母的含義
ISO 8601時長以P(period)開頭。接下來是日期部分的各個成分,每個都是數字加上單位字母:Y表示年,M表示月,W表示週,D表示日。T用來分隔日期部分和時間部分:H表示小時,M表示分鐘,S表示秒。每個成分都是可選的,只寫需要的部分即可。PT15M是15分鐘,P1DT2H是1天2小時,P3W是3週。T不是可有可無的裝飾:M在T之前表示月,在T之後表示分鐘,所以P1M是1個月,而PT1M是1分鐘。最後出現的那個成分可以帶小數,比如PT0.5S表示半秒。而且各個單位不會自動進位:PT90M是表示一個半小時的完全有效寫法。
你實際會在哪裡遇到這種格式
這種語法幾乎無處不在,只是不太引人注意。YouTube Data API把每段影片的時長都回報為ISO 8601時長(PT4M13S)。HTML在time元素的datetime屬性裡接受時長寫法。行事曆邀請也在用它:iCalendar標準(RFC 5545)把活動時長寫成PT1H0M0S這樣的形式,不過它的文法裡去掉了年和月。XML Schema的xs:duration涵蓋了完整形式,甚至允許在前面加負號來表示負時長。標準函式庫可以直接解析它:java.time用Period.parse和Duration.parse來讀取P和T字串,很多其他語言裡也有類似的劃分。如果你要產生機器可讀的排程、訂閱源或API,這種格式就是表達「多長時間」的通用語言。
為什麼P1M不是固定的秒數
PT15M永遠是900秒。P1M不是:一個月是28天、29天、30天還是31天,取決於它從哪天開始,所以P1M只有綁定到具體日期之後才會變成一個確定的值。就連P1D也不能保證是24小時。在歐盟,2026年3月29日星期日會撥快時鐘,所以那一天在日曆上只有23小時:在同一個週六晚上分別加上P1D(一個日曆日)和加上PT24H(整整24小時),會落到不同的時刻上。這正是java.time要區分Period(日曆單位)和Duration(精確秒數)兩種型別的原因,也是日期函式庫在轉換時長之前要先要求一個參考日期的原因。請把Y、M、W、D這幾個成分當作日曆運算來處理,只有H、M、S才是固定不變的時間量。
不是時長:20260424174227.0Z
像20260424174227.0Z這樣的字串看起來可能屬於同一個家族,但它其實是一個時間戳記,而不是時長,也不屬於ISO 8601。它是GeneralizedTime,來自ASN.1的一種格式,是LDAP目錄和X.509憑證使用的記法。可以把它當成固定寬度的欄位來讀:年份2026,月份04,日期24,接著是17:42:27,一個可選的小數部分(.0),以及表示UTC的Z。你會在Active Directory的whenCreated和whenChanged等屬性、LDAP匯出結果,以及憑證內部見到它,RFC 5280要求2050年及以後的有效期日期使用GeneralizedTime。區分它和ISO 8601簡潔形式的關鍵線索是缺少T:如果是ISO寫法,同一個時刻會寫成20260424T174227Z。
不看規範也能讀懂
如果只是要解讀一個字串,我們的ISO 8601時間長度轉換器可以把任意P/T時長解析成各個成分以及總秒數,也可以根據你輸入的數字反向拼出字串。如果你手邊的不是時長字串,而是兩個具體的時刻(比如一個從22:00到06:30的班次),時間長度計算器能算出經過的時間,包括跨越午夜的情況。這兩個工具都完全在你的瀏覽器裡運作:你輸入的內容不會離開你的裝置。如果不借助工具也想快速讀懂,記住兩個訣竅就能應付大多數情況:先找T,判斷M是月還是分鐘;記住T左邊的一切都是日曆運算,而不是固定的秒數。
本文涉及的工具
常見問題
PT1M和P1M是一回事嗎?
不是。字母M在T這個分隔符號兩側含義不同:P1M是1個月,PT1M是1分鐘。這是這種格式裡最常見的誤讀,也曾因此導致API出現過上線的漏洞。拿不準的時候,先找T:T之前的一切按年、月、週、日計數;T之後的一切按小時、分鐘、秒計數。一個格式正確的時長,不會在T之前出現時間單位,也不會在T之後出現日期單位。
90分鐘該怎麼寫成ISO 8601時長?
PT90M和PT1H30M都是合法的寫法,表示的是同一段時間。ISO 8601不要求各個成分落在常規範圍內,所以分鐘數超過59或小時數超過23都沒問題。剖析器兩種寫法都能接受;至於系統會輸出哪一種,取決於它是否做了正規化處理。如果你產生的時長是給人讀的,PT1H30M更友善;如果你在程式碼裡比較時長,應該比較總秒數而不是字串本身,正因為兩個不同的字串可能表示同一件事。
時長和區間有什麼區別?
時長只說明有多長,不涉及日曆上的具體位置:P3D是3天,從哪天開始都可以。ISO 8601的區間會用斜線把時長綁定到實際日期上:2026-07-04T00:00:00Z/P3D表示從2026年7月4日開始的3天,而像2026-07-04/2026-07-07這樣的起訖日期對表達的是同一段區間。還有帶R前綴的重複區間:R5/2026-07-04T00:00:00Z/P1D表示從那個起始時刻開始,每天重複5次。區間解決了日曆單位的歧義,因為綁定到具體日期之後,P1M總是有一個確定的長度。