【问题标题】:Set default timezone H2 database设置默认时区 H2 数据库
【发布时间】:2012-10-21 23:48:08
【问题描述】:

如何明确设置 H2 应使用的时区?现在它从底层操作系统获取要使用的时区。我假设存在一个额外的参数,我将添加到连接字符串中,如下所示。

db.url=jdbc:h2:mem:mybipper;MVCC=true;<timezone=UTC>

【问题讨论】:

  • 你想解决什么问题?我不知道 H2 对大多数操作使用时区(至少不是 H2 的当前版本)。
  • 在美国本地时区存储时间戳时,夏令时会在时间戳位于“回滚小时”内时导致信息丢失,其中每个可能的时间戳值在 2 小时内出现两次。常见的解决方法是将数据库设置为 UTC,或者使用字符串/长整数来编码日期,或者添加一个时区偏移字段来补偿 DST。

标签: h2


【解决方案1】:

显然您在连接上没有参数,但数据库将使用加载驱动程序的 JVM 的时区,因此您可以设置-Duser.timezone=UTC请注意,加载驱动程序后,您无法更改时区。

【讨论】:

    【解决方案2】:

    您可以在与数据库交互之前操纵 JVM 时区:

    TimeZone.setDefault(TimeZone.getTimeZone("UTC"))
    

    不幸的是,H2 还不支持每个连接的时区...。

    【讨论】:

    • 谢谢。我在依赖Java.Instant 和H2 DB 的测试的@BeforeClass 方法中添加了这个。 Instant 生成 UTC 时间戳,而 H2 DB 将其转换为 UTC+2。
    • 仅适用于应用程序,但在具有不同时区的机器上运行时仍会中断测试。
    【解决方案3】:

    帮助我的是为 JDBC 而不是 JVM 设置时区配置,这似乎也更合理和更干净的方式,因为它只影响数据库而不是整个 JVM:

    spring.jpa.properties.hibernate.jdbc.time_zone=UTC
    

    My answer 到另一个问题可能有助于提供更多信息。

    【讨论】:

    • 这按预期工作。将此属性添加到 application.properties 会将内存中数据库的时区设置为所需的时区。
    【解决方案4】:

    H2 使用 JVM 时区,它会影响您的日期计算。例如,如果您在 Junits 中使用它,您可以设置某个时区,然后在完成后重新输入初始值。示例:

    System.setProperty("user.timezone", "GMT-3");
    TimeZone.setDefault(null);
    

    【讨论】:

    • 只是想用System.setProperty("user.timezone", "GMT"); 说这个答案对我有用。 H2 没有收到我通过 TimeZone.setDefault() 所做的任何事情。
    【解决方案5】:

    我想你在阅读DateDateTime 类型时会看到这样的“不当行为”。

    显然H2在写入和读取时使用了不同的时区信息。提供带有预期时区的日历会为我返回预期值:

    Calendar cal = Calendar.getInstance(TimeZone.getTimeZone(ZoneOffset.UTC))
    resultSet.getDate("dateColumn", cal)
    

    【讨论】:

      【解决方案6】:

      您不能为数据库设置时区。

      但是,我不知道 H2 对大多数操作使用时区(至少不是 H2 的当前版本)。

      那么,你想解决什么问题?

      【讨论】:

      • 如果您从 MySql 导出一些数据,则日期时间将采用 UTC 格式。如果您随后将其导入不在 UTC 服务器上的 H2 实例(例如运行测试时的本地机器),H2 将转换日期时间,认为它们在您的本地机器区域中。数据将不再匹配。您可以编辑 SQL 以将 +00:00 添加到所有日期时间,这将解决问题,但 MySql(某些版本)不再识别。
      • 嗯,这听起来很像 MySQL 方面的问题。您目前如何导出数据?也许您想问另一个关于如何使用本地时区导出的问题?
      • 可能我解释得不好。如果您在一个时区从 H2 导出然后在另一个时区重新导入,也会发生同样的事情。这是因为日期时间在数据库中没有时区。这就是 H2 的设计方式,它记录在 their docs 中。有时这是可取的,有时则不是。
      • 由于这种行为,我遇到了一个非常大的问题... TIME 数据不一致... 因为 DST?时区变化?现在我有很多数据库,其中包含明智和重要的 TIME 数据(用于数字签名信息)完全搞砸了:\\\\
      • 还有更多...在原始时区之外访问的任何 TIME 字段都是错误的! @ThomasMueller,我需要帮助来解决这个问题......:|
      猜你喜欢
      • 2012-12-21
      • 2021-06-05
      • 2021-01-06
      • 2014-07-15
      • 2013-02-16
      • 2021-11-19
      • 1970-01-01
      • 2015-07-01
      • 2017-01-05
      相关资源
      最近更新 更多