在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的工作方式。
H2 JDBC驱动程序
PrepStmt.setDate(int,Date)使用
ValueDate.get(Date)，该调用
DateTimeUtils.datevalueFromDate(long)进行时区转换。
使用此SQLite JDBC驱动程序，
PrepStmt.setDate(int, Date)调用
PrepStmt.setObject(int,Object)并且不进行任何时区转换。
H2
JDBC驱动程序
JdbcResultSet.getDate(int)返回
get(columnIndex).getDate()。
get(int)返回
Value指定列的H2
。由于列类型为
DATE，因此H2使用
ValueDate。
ValueDate.getDate()调用
DateTimeUtils.convertDatevalueToDate(long)，最终会
java.sql.Date在时区转换后创建一个。
使用此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提供一个系统都是不可行的，最终将导致比解决的问题更多的问题。
