java select 不是date_SQL DATE和java.sql.Date中的时区

JDBC specification没有定义关于时区的任何细节。尽管如此，我们大多数人知道必须处理JDBC时区差异的痛苦;只看看所有

StackOverflow questions！

最终，日期/时间数据库类型的时区处理归结为数据库服务器，JDBC驱动程序和之间的一切。你甚至在JDBC驱动程序错误的怜悯; PostgreSQL修复了一个bug in version 8.3在哪里

Statement.getTime, .getDate, and .getTimestamp methods which are passed a Calendar object were rotating the timezone in the wrong direction.

当您使用新的Date(0)创建新日期时(让我们断言您正在使用Oracle JavaSE java.sql.Date，您的日期已创建

using the given milliseconds time value. If the given milliseconds value contains time information, the driver will set the time components to the time in the default time zone (the time zone of the Java virtual machine running the application) that corresponds to zero GMT.

所以，新的Date(0)应该使用GMT。

当您调用ResultSet.getDate(int)时，您正在执行JDBC实现。 JDBC规范不规定JDBC实现应该如何处理时区详细信息;所以你执行的怜悯。查看Oracle 11g oracle.sql.DATE JavaDoc，似乎Oracle DB不存储时区信息，因此它执行自己的转换以将日期导入java.sql.Date。我没有使用Oracle DB的经验，但我猜测JDBC实现使用服务器和本地JVM的时区设置来执行从oracle.sql.DATE到java.sql.Date的转换。

你提到多个RDBMS实现正确处理时区，除了SQLite。让我们看看H2和SQLite如何工作，当您发送日期值到JDBC驱动程序，当您从JDBC驱动程序获取日期值。

使用这个SQLite JDBC driver，RS.getDate(int)代码要简单得多;它只是使用存储在数据库中的长日期值返回java.sql.Date。

因此，我们看到H2 JDBC驱动程序聪明地处理时区转换与日期，而SQLite JDBC驱动程序不是(不是说这个决定不聪明，它可能适合SQLite设计决策好)。如果你跟着你提到的其他RDBMS JDBC驱动程序的源，你可能会发现，大多数是接近的日期和时区，以类似的方式H2如何。

虽然JDBC规范没有详细说明时区处理，但RDBMS和JDBC实现设计者考虑时区并正确处理它是很有意义的;特别是如果他们希望他们的产品在全球舞台上销售。这些设计师都很聪明，我并不惊讶，大多数他们得到这个权利，即使没有一个具体的规范。

我发现这个Microsoft SQL Server博客，Using time zone data in SQL Server 2008，这解释了时区如何复杂的事情：

timezones are a complex area and each application will need to address how you are going to handle time zone data to make programs more user friendly.

Unfortunately, there is no current international standard authority for timezone names and values. Each system needs to use a system of their own choosing, and until there is an international standard, it is not feasible to try to have SQL Server provide one, and would ultimately cause more problems than it would solve.