2025年9月25日: PostgreSQL 18 釋出!
支援的版本: 當前 (18) / 17 / 16 / 15 / 14 / 13
開發版本: devel
不支援的版本: 12 / 11 / 10 / 9.6 / 9.5 / 9.4

B.2. 無效或模糊時間戳的處理 #

通常,如果日期/時間字串在語法上有效但包含超出範圍的欄位值,則會引發錯誤。例如,指定 2 月 31 日的輸入將被拒絕。

在夏令時轉換期間,一個看似有效的時間戳字串可能會表示一個不存在或模糊的時間戳。這種情況不會被拒絕;歧義透過確定應用哪個 UTC 偏移量來解決。例如,假設 TimeZone 引數設定為 America/New_York,考慮

=> SELECT '2018-03-11 02:30'::timestamptz;
      timestamptz
------------------------
 2018-03-11 03:30:00-04
(1 row)

因為那天在該時區是春季前進轉換日期,所以沒有民用時間瞬間凌晨 2:30;時鐘從東部標準時間 (EST) 凌晨 2 點向前跳到東部夏令時 (EDT) 凌晨 3 點。PostgreSQL 將給定時間解釋為標準時間 (UTC-5),然後渲染為 EDT (UTC-4) 凌晨 3:30。

相反,考慮秋季回退轉換期間的行為

=> SELECT '2018-11-04 01:30'::timestamptz;
      timestamptz
------------------------
 2018-11-04 01:30:00-05
(1 row)

在那天,凌晨 1:30 有兩種可能的解釋;有 EDT 凌晨 1:30,然後一個小時後,時鐘從 EDT 凌晨 2 點跳回到 EST 凌晨 1 點,有 EST 凌晨 1:30。同樣,PostgreSQL 將給定時間解釋為標準時間 (UTC-5)。我們可以透過指定夏令時來強制其他解釋

=> SELECT '2018-11-04 01:30 EDT'::timestamptz;
      timestamptz
------------------------
 2018-11-04 01:30:00-04
(1 row)

在這種情況下應用的精確規則是,出現在夏令時跳進轉換期間的無效時間戳將被賦予轉換前該時區存在的 UTC 偏移量,而可能落在跳回轉換任一側的模糊時間戳將被賦予轉換後該時區存在的 UTC 偏移量。在大多數時區中,這相當於說“如有疑問,優先選擇標準時間解釋”。

在所有情況下,都可以使用數值 UTC 偏移量或對應於固定 UTC 偏移量時區縮寫來顯式指定與時間戳關聯的 UTC 偏移量。僅當需要推斷在偏移量變化的特定時區中 UTC 偏移量時,才適用上述規則。

提交更正

如果您在文件中發現任何不正確、與您在使用特定功能時的體驗不符或需要進一步澄清的內容,請使用此表格報告文件問題。