相关疑难解决方法(0)

我们有一个简单的实用程序应用程序,它可以读取JRE中使用的所有时区数据,并将其全部显示在一个简单的表中.我们需要使用较旧版本的JRE(6_24)来发布即将发布的产品(由于显然存在其他问题),但我们还需要在该版本中包含更新的时区更新(否则将包含在6_29中) ).我们已经打包了一个将要安装的私有JRE,因此使用TZUpdater工具将时区更新到该私有JRE 不是问题 - 问题是读取/验证tzdata的哪个版本(例如tzdata2010o,tzdata2011k)是正在使用实用程序应用程序读取(即正在运行应用程序的JRE中使用的是哪个版本).该应用程序当前在标题栏中显示JRE版本,但随着时区更新,这已不再足以确定正在使用的时区数据版本.

我查看了TimeZone类,但它似乎没有提供这些信息 - 也许有一个系统属性可以保存这些信息？TZUpdater工具知道正在使用哪个版本,所以它必须在某个地方可用 - 我无法想象他们会在分析中确定更新工具中正在使用哪个版本...有谁知道在哪里找到这个信息？

我们最近将应用程序从 Java 11 过渡到 Java 17。部署后，我们注意到某些记录存在差异，其中日期显示有一日差异 (+1)。这种情况尤其发生在 1940 年之前的记录中。我们的应用程序在 CEST 时区运行，日期在 MongoDB 中存储为 UTC。以下示例重点介绍了我们已发现问题的实例。

提供的代码片段是用 Kotlin 编写的，在 Java 11 中产生令人满意的结果。但是，当使用 Java 17 执行时，相同的代码无法按预期运行。

fun main() {  // Kotlin code
    val date = Date(-1118625572000) //1934-07-21T22:40:28.000+00:00
    println("Date: ${date.toInstant()?.atZone(ZoneId.of("Europe/Amsterdam"))!!.toLocalDate()}")
}

Java11 输出：

Java17 输出：

Java 17 中是否有可用的解决方案来解决与这些类型的日期相关的问题？

我们尝试直接在数据库中更正这些记录，以确保有效日期的数量。

例如，

1934-07-21T22:40:28.000+00:00 --> 1934-07-22T00:00:00.000+00:00
1897-08-06T23:40:28.000+00:00 --> 1897-08-07T00:00:00.000+00:00

然而，我们需要探索是否有一种方法可以在 Java 17 中专门处理这些类型的日期。