【问题标题】:LocalDateTime to milliseconds difference in Java 8 and Java 11Java 8 和 Java 11 中 LocalDateTime 到毫秒的差异
【发布时间】:2021-08-19 08:11:06
【问题描述】:

我目前正在将一些项目从 Java 8 升级到 Java 11,其中一个转换器的单元测试失败了。基本上,问题源于由于之前通过 JDK 8 传递的日期精度而导致相等性检查失败。

这是测试的部分示例,为了清楚起见,我移动了转换器的内容:

@Test
public void testDateTime() {
    LocalDateTime expected = LocalDateTime.now().plusDays(1L);

    // converter contents
    long epochMillis = expected.atZone(ZoneId.systemDefault())
            .toInstant().toEpochMilli();
    LocalDateTime actual = LocalDateTime.ofInstant(Instant.ofEpochMilli(epochMillis),
            TimeZone.getDefault().toZoneId());


    assertThat(actual, equalTo(expected));
}

这会导致资产错误,原因是:

Expected :<2021-06-02T14:06:21.820299>
Actual   :<2021-06-02T14:06:21.820>

我可以用assertThat(actual, equalTo(expected.truncatedTo(ChronoUnit.MILLIS))) 对预期进行中继以使它们相等,但是,这意味着每次与正在测试的转换器类进行比较(isAfter、isBefore、等于)时,都必须应用中继。

对于 JDK 11(或者我可能错过的文档 :)),是否有适当的方法在 LocalDateTimeLong 之间进行转换?


更新:

正如 cmets 中所指出的,Java 8 和 11 的表示方式不同,因此导致测试失败。为了提供更多关于这篇文章所要求的内容,这里有两种方法正在被测试验证(我移动到测试本身只捕获正在执行的内容,因为失败的单元测试属于使用的类实用方法)

public Long localDateTimeToEpochMillis(LocalDateTime ldt) {
    Instant instant = ldt.atZone(ZoneId.systemDefault()).toInstant();
        return ldt.atZone(ZoneId.systemDefault())
           .toInstant().toEpochMilli();
}

public LocalDateTime epochMillisToLocalDateTime(long epochMillis) {
    return LocalDateTime.ofInstant(
            Instant.ofEpochMilli(epochMillis), 
            ZoneId.systemDefault());
}

现有测试似乎验证的是,给定一个 long 值,我应该得到相同的 LocalDateTime 等效值,这是通过使用 Given(LocalDateTime 转换为 Long 值)然后返回 LocalDateTime 进行比较来完成的。

【问题讨论】:

  • 您是否尝试过 Instant.ofEpochSecond​ 并将 Instant.getNano() 作为第二个参数传递?或者最好只使用 Instant 而不是毫秒和纳秒。
  • 我相信这个问题更多地围绕着 Java-8 和 Java-11 之间的期望不匹配。但为此,您可能需要说明当前测试所依赖的假设或文档。
  • 不幸的是我不能,有些情况下需要长值(即与protobuf相关的转换等)。另一方面,使用 nanoAdjustment 作为 ofEpochSecond 的第二个参数是可行的。
  • 你还没有解释这实际上应该测试什么。因此我们无法告诉您您的测试代码是否正确。
  • 顺便说一句,我无法想象在任何情况下调用LocalDateTime.now 是正确的做法。该类故意缺少时区的上下文或与 UTC 的偏移量,因此它不能代表一个时刻,它不是时间线上的特定点。 Instant.now() 应该用于捕捉当前时刻。

标签: java java-8 java-11 localdatetime


【解决方案1】:

如果你看一下区别:

Expected :<2021-06-02T14:06:21.820299>
Actual   :<2021-06-02T14:06:21.820>

您可以看到它会在不到一毫秒的时间内删除任何内容。

发生这种情况是因为您将 LocalDateTime 转换为毫秒:

.toInstant().toEpochMilli();

为了避免这种情况,你可以使用Instant#getNano:

获取从一秒开始到时间线后面的纳秒数。 纳秒秒值测量从 getEpochSecond() 返回的秒算起的总纳秒数。

它可能看起来像这样:

Instant instant=expected.atZone(ZoneId.systemDefault())
                .toInstant();
long epochMillis = instant.toEpochMilli();
long nanos=instant.getNano()%1000000;//get nanos of Millisecond

LocalDateTime actual = LocalDateTime.ofInstant(Instant.ofEpochMilli(epochMillis).plusNanos(nanos),
        TimeZone.getDefault().toZoneId());

为什么它在 Java 8 中有效?

正如this postJDK-8068730 Increase the precision of the implementation of java.time.Clock.systemUTC() 所描述的,Java 8 没有捕获小于一毫秒的时间单位。从 Java 9 开始,LocalDateTime.now(和类似的)以微秒为单位获取时间。

【讨论】:

  • 您是说当前的测试有误吗?否则这是迁移到 Java-11 的便捷方式吗?
  • 测试似乎是“错误的”,至少对于 Java 11,因为它截断了纳秒。
  • 当前测试不准确。这有点像比较double 值并首先将其中一个转换为整数。 @纳曼
  • Java 8 中也存在这个问题,但您没有用微秒/纳秒测量时间。查看我的编辑。
猜你喜欢
  • 2014-07-19
  • 2019-02-12
  • 2021-05-25
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 2017-12-19
相关资源
最近更新 更多