SQL的CURRENT_TIMESTAMP（在JDBC上使用时）是否与时区无关？

Question

在Apache OAK中，我们使用SQL的CURRENT_TIMESTAMP向数据库询问当前时间的概念（不是为了存储它，而是为了验证与数据库通信的所有Oak实例具有大致相同的系统时间）。 / p>

使用JDBC ResultSet和getTimestamp().getTime()接收值，该值应返回适合与System.currentTimeMillis()进行比较的值。

这似乎有效，直到有人试图连接到在不同时区运行的IBM DB2实例，在这种情况下，返回的时间戳由TZ差异（或可能是DST偏移常量）关闭 - 详细信息在{{ 3}}

所以问题是：

1. 这是DB2或其JDBC驱动程序的已知问题吗？
2. 其他数据库也会发生这种情况吗？
3. 是否有可靠且可移植的替代方案？

Answer 1

问题是JDBC规范要求驱动程序在没有时区信息的情况下解释TIME（或TIMESTAMP），就好像该值在JVM的本地时区中一样。另请参阅Is java.sql.Timestamp timezone specific?

举个例子。您的数据库服务器是UTC，而CVM是CET（UTC + 1）。 UTC中的当前时间是10:00，这意味着如果您要求当前时间，那么它是＆＃34; 10:00＆＃34;在服务器上。 TIME数据类型没有时区，因此当JVM查询时，它必须将其转换为平均值＆＃34; 10：00＆＃34;在当地时区。所以结果是10:00 CET，（也就是9:00 UTC），换句话说：相差一小时。

根据提供的信息，它听起来像DB2驱动程序正在做它应该做的事情。

不幸的是，并非所有JDBC驱动程序都能正确执行此操作，更糟糕的是，某些驱动程序可以配置为表现不同。

Answer 2

在DB2中，CURRENT_TIMESTAMP的值始终表示数据库服务器操作系统时间。您可以使用CURRENT_TIMEZONE值将值标准化为UTC;从CURRENT_TIMESTAMP中减去它将产生UTC时间戳：

SELECT CURRENT_TIMESTAMP - CURRENT_TIMEZONE AS timestamp_UTC FROM sysibm.sysdummy1