小編典典

在JDBC規范不問候時區定義的任何細節。盡管如此，我們大多數人都知道必須處理JDBC時區差異的痛苦。

最終，日期/時間數據庫類型的時區處理歸結為數據庫服務器，JDBC驅動程序以及兩者之間的所有內容。您甚至受JDBC驅動程序錯誤的支配。PostgreSQL修復了版本8.3中的錯誤，其中

傳遞給Calendar對象的Statement.getTime，.getDate和.getTimestamp方法使時區朝錯誤的方向旋轉。

當您使用創建新日期時new Date(0)(假設您正在使用Oracle JavaSE

java.sql.Date，則會創建您的日期

使用給定的毫秒時間值。如果給定的毫秒值包含時間信息，則驅動程序會將時間分量設置為默認時區(運行應用程序的Java虛擬機的時區)中與GMT零相對應的時間。

因此，new Date(0)應使用GMT。

調用時ResultSet.getDate(int)，您正在執行JDBC實現。JDBC規范沒有規定JDBC實現應如何處理時區細節。因此，您無法實現。從Oracle

11g

oracle.sql.DATEJavaDoc看，Oracle

DB似乎沒有存儲時區信息，因此它執行自己的轉換以將日期轉換為java.sql.Date。我沒有使用Oracle

DB的經驗，但是我想JDBC的實現是使用服務器的本地JVM的時區設置來進行從oracle.sql.DATE到的轉換java.sql.Date。

您提到了多個RDBMS實現可以正確處理時區，但SQLite除外。讓我們看一下將日期值發送到JDBC驅動程序以及從JDBC驅動程序獲取日期值時H2和SQLite的工作方式。

使用此SQLite JDBC驅動程序，RS.getDate(int)代碼要簡單得多。它只是java.sql.Date使用long存儲在數據庫中的日期值返回a

。

因此，我們看到H2 JDBC驅動程序在處理帶日期的時區轉換方面很聰明，而SQLite

JDBC驅動程序則不明智(并不是說這個決定不明智，它可能很適合SQLite設計決定)。如果您追查提到的其他RDBMS

JDBC驅動程序的源代碼，則可能會發現大多數驅動程序都以與H2相似的方式接近日期和時區。

盡管JDBC規范沒有詳細說明時區處理，但是RDBMS和JDBC實現設計人員考慮時區并會正確處理時區是很有意義的。特別是如果他們希望自己的產品在全球舞臺上可銷售。這些設計師非常聰明，即使沒有具體規范，大多數人也都能做到這一點，我對此并不感到驚訝。

我在Microsoft SQL Server博客中找到了使用SQL Server

2008中的時區數據，它說明了時區如何使事情變得復雜：

時區是一個復雜的區域，每個應用程序都需要解決如何處理時區數據的問題，以使程序更加用戶友好。

不幸的是，當前沒有時區名稱和值的國際標準權威。每個系統都需要使用自己選擇的系統，并且直到有國際標準之前，嘗試讓SQL

Server提供一個系統都是不可行的，最終將導致比解決的問題更多的問題。

2020-09-11

總結

以上是生活随笔為你收集整理的java 中的sql.date_SQL DATE中的时区vs java.sql.Date的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。