java 中的sql.date_SQL DATE中的时区vs java.sql.Date

小编典典

在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