小编典典
在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