我想用時區（ 2 小時）更新日期，但它最終為 UTC（0 小時）

日期型別是 'timestamp-with-timezone'

詢問...

update table set date = '2022-05-25 13:28 02:00'

將在資料庫中結束。

2022-05-25 11:28:00 00

這里有什么問題？

uj5u.com熱心網友回復：

tl;博士

沒有錯。Postgres 以 UTC 存盤值TIMESTAMP WITH TIME ZONE，總是與 UTC 的偏移量為零。任何提交的偏移量或區域都用于調整到 UTC。

細節

日期型別是 'timestamp-with-timezone'

標準 SQL 和 Postgres 中都沒有這種型別。

我假設你的意思是TIMESTAMP WITH TIME ZONE.

它以 UTC 結尾（0 小時）

閱讀精美的手冊。您正在看到記錄在案的行為。

Postgres 始終將值存盤TIMESTAMP WITH TIME ZONE在 UTC 型別的列中，即偏移量為零時分秒。

輸入提供的任何時區或偏移量都用于調整為 UTC。然后丟棄提供的區域或偏移量。

所以型別的名稱TIMESTAMP WITH TIME ZONE是用詞不當。首先，SQL 的作者考慮的是偏移量，而不是實時時區。其次，不存盤任何提交的時區。提交的區域用于調整然后丟棄。

如果您需要跟蹤原始偏移量或區域，請添加額外的列。您必須添加代碼來存盤偏移量或時區名稱。

update table set date = '2022-05-25 13:28 02:00'將在資料庫中結束。2022-05-25 11:28:00 00這里有什么問題？

沒有什么是錯的。這是一個特性，而不是一個錯誤。這兩個字串都代表相同的同時時刻。

僅供參考，資料庫引擎在處理日期時間型別和行為的行為方面差異很大。

有些人像 Postgres 所做的那樣TIMESTAMP WITH TIME ZONE，調整到 UTC，然后丟棄任何提供的時區或偏移量。其他一些可能不會。

SQL 標準幾乎沒有涉及日期時間處理的主題。它宣告了幾種型別，并且在所有情況下都覆寫不完整的情況下做得很差。該標準忽略了定義行為。

因此，在資料庫作業中處理日期時間時要非常小心。仔細閱讀特定資料庫引擎的檔案。不要做假設。運行實驗以驗證您的理解。并且知道為日期時間撰寫可移植的 SQL 代碼可能不可行。

轉載請註明出處，本文鏈接：https://www.uj5u.com/qita/481676.html