支援的版本:目前 (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:30AM; 時鐘從凌晨 2 點 EST 跳到凌晨 3 點 EDT。PostgreSQL 會將給定的時間解釋為標準時間 (UTC-5),然後呈現為凌晨 3:30 EDT (UTC-4)。

相反地,考慮一下在秋季回溯轉換期間的行為

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

在該日期,對凌晨 1:30 有兩種可能的解釋; 凌晨 1:30 EDT,然後在一小時後,時鐘從凌晨 2 點 EDT 跳回凌晨 1 點 EST,有凌晨 1:30 EST。 同樣地,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 偏移量時。

提交更正

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