UTC Unix时间戳存储在错误时区的Java程序HSQLDB中

Question

我试图了解如何将Unix时间戳 (即1970年以来在UTC/GMT时区中表示的若干秒)存储在HSQLDB嵌入式文件数据库中。然而，我还没有理解TZ处理如何与HSQL一起工作。

我的程序将从不同的区域使用，所以使用UTC是必须的。此外，我不能更改默认时区(与java.util.TimeZone.setDefault一样)，因为它将嵌入到其他程序中，因此不应该更改环境。

我的尝试-文档声明：

当使用PreparedStatement或CallableStatement接口将日期时间值发送到数据库时，Java将转换为已准备或可调用的语句参数的类型。此类型可能是日期、时间或时间戳(带时区或不带时区)。时区位移是JDBC会话的时区。

因此，我在数据库中使用一个时间戳列(没有时区-默认值)，并发出SET TIME ZONE INTERVAL '0:00' HOUR TO MINUTE (将会话放在UTC中)，然后发出INSERT INTO TEST VALUES(?) with？是一个包含正确Unix值的Java时间戳对象(GMT相关的，测试确定)。

遗憾的是，在这种情况下，数据库的SQL日志显示时间戳已被还原回我的本地时区(+2)。对于1442132237635的时间戳( UTC中的8H17，+2中的10H17 )，我们在日志中得到TIMESTAMP'2015-09-13 10:17:17.602000'。错误的结果..。似乎改变会议时区绝对没有任何影响(我试过+14，-14.(无变动)。然而，SET顺序是正确执行的-它出现在SQL日志中，而TIMEZONE()的值随后会发生变化。

其他尝试

我还尝试使用时区列的时间戳，而不设置会话TZ。在这种情况下，数据库存储‘本地时间+2'，我可以从中提取正确的时间戳。这有点荒谬--这意味着HSQLDB驱动程序获取Java时间戳(UTC)，将其正确解释为UTC，将其转换为JVM默认的TZ，然后将其发送给DB。我不想要数据库里的TZ信息-不需要。(注意:更改会话TZ没有影响-发出的SQL命令总是与我的本地TZ.使您想知道设置TZ订单的目的是什么)

并且将默认的JVM TZ更改为UTC有效，但如上所述，我不能这样做。

另外要注意的是：这个问题似乎是相关的，但提供的答案基本上是破解我想要避免的每一个SQL顺序。

我的问题

如何简单地将UTC Java时间戳存储在HSQLDB中？设置时区顺序的目的是什么？

感谢您的阅读。

Answer 1

您的第一次尝试是正确的，并将返回正确的结果。

您的数据库位于UTC+2时区。您正在连接，就像您是UTC时区中的远程用户一样。

时间戳的日志存储并不像您所说的那样是错误的。日志存储不供数据库用户读取。数据库将其日志存储在位置的时区中。下次它读取日志时，它会根据您的数据库时区(与会话时区无关)读取和解释日志。因此，在UTC日志中存储的时间为10:17，为8:17。

使用没有时区的时间戳，数据库文件不能移动到不同的时区，因为时间戳将根据新位置的区域进行解释。

SET时区语句的作用是允许在存储数据时进行正确的调整。它不会更改以前存储的数据。当然，如果一个时间被存储为8:17，那么它应该被读取为8:17，无论何时在哪个区域访问它。

为获得最佳的可移植性，请使用带有时区的时间戳。即使您移动数据库文件，它存储和检索数据的方式也是正确的。