Java 8 和 Java 11 中的 LocalDateTime 毫秒差
LocalDateTime to milliseconds difference in Java 8 and Java 11
我目前正在将一些项目从 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)))
对预期进行中继以使它们相等,但是,这意味着每次对正在测试的转换器 class 进行比较(isAfter、isBefore、等于)时,必须应用中继。
是否有正确的方法在 LocalDateTime
到 Long
之间进行转换,反之亦然 JDK 11(或者我可能错过的文档 :))?
更新:
正如评论中指出的那样,Java 8 和 11 的表示形式不同,因此导致测试失败。为了提供更多关于此 post 所要求内容的上下文,这里是测试验证的 2 种方法(我将其移至测试本身以仅捕获正在执行的内容,因为失败的单元测试属于使用实用方法的 class)
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 进行比较来完成的。
如果你看一下区别:
Expected :<2021-06-02T14:06:21.820299>
Actual :<2021-06-02T14:06:21.820>
您可以看到它删除了不到一毫秒的任何内容。
发生这种情况是因为您将 LocalDateTime
转换为毫秒:
.toInstant().toEpochMilli();
为了避免这种情况,您可以使用 Instant#getNano
:
Gets the number of nanoseconds, later along the time-line, from the start of the second.
The nanosecond-of-second value measures the total number of nanoseconds from the second returned by 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 中有效?
如 and JDK-8068730 Increase the precision of the implementation of java.time.Clock.systemUTC()所述,Java8没有捕获小于毫秒的时间单位。由于 Java 9,LocalDateTime.now
(以及类似的)以微秒为单位获取时间。
我目前正在将一些项目从 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)))
对预期进行中继以使它们相等,但是,这意味着每次对正在测试的转换器 class 进行比较(isAfter、isBefore、等于)时,必须应用中继。
是否有正确的方法在 LocalDateTime
到 Long
之间进行转换,反之亦然 JDK 11(或者我可能错过的文档 :))?
更新:
正如评论中指出的那样,Java 8 和 11 的表示形式不同,因此导致测试失败。为了提供更多关于此 post 所要求内容的上下文,这里是测试验证的 2 种方法(我将其移至测试本身以仅捕获正在执行的内容,因为失败的单元测试属于使用实用方法的 class)
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 进行比较来完成的。
如果你看一下区别:
Expected :<2021-06-02T14:06:21.820299>
Actual :<2021-06-02T14:06:21.820>
您可以看到它删除了不到一毫秒的任何内容。
发生这种情况是因为您将 LocalDateTime
转换为毫秒:
.toInstant().toEpochMilli();
为了避免这种情况,您可以使用 Instant#getNano
:
Gets the number of nanoseconds, later along the time-line, from the start of the second. The nanosecond-of-second value measures the total number of nanoseconds from the second returned by 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 中有效?
如LocalDateTime.now
(以及类似的)以微秒为单位获取时间。