如何证明 2015 年 6 月 30 日在 Java 8(新的日期时间 API)中有 86401 秒

Question

我试图证明 2015 年 6 月 30 日有 86401 秒，使用 Java 代码如下：

Instant i1 = Instant.ofEpochSecond(longestDay.toEpochSecond(ZoneOffset.UTC));
Instant i2 = Instant.ofEpochSecond(oneDayAfter.toEpochSecond(ZoneOffset.UTC));
long d = i1.until(i2, ChronoUnit.SECONDS);
System.out.println(d);
// 86400

我再试一次：

LocalDateTime longestDay = LocalDateTime.of(2015, Month.JUNE, 30, 0, 0, 0);
LocalDateTime oneDayAfter = LocalDateTime.of(2015, Month.JULY, 1, 0, 0, 0, 0);      
long p = ChronoUnit.SECONDS.between(longestDay, oneDayAfter);
System.out.println("p = " + String.valueOf(p));
// Result: p = 86400

仍然没有成功

我仍然再试一次：

ZonedDateTime startZdt = ZonedDateTime.of( 2015, 06, 30, 23, 59, 59, 00, ZoneOffset.UTC );
ZonedDateTime stopZdt = ZonedDateTime.of( 2015, 07, 01, 00, 00, 00, 00, ZoneOffset.UTC );
long elapsed = startZdt.until( stopZdt,ChronoUnit.SECONDS);
System.out.println("elapsed: " + elapsed);
// Result: elapsed: 1

我无法通过 Java 代码证明 2015 年 6 月 30 日有 86401 秒。帮我做这个！

Answer 1

简短回答：

不。正如您已经证明的那样，没有机会用java.time(JSR-310(来证明这一点。

解释：

• 为了启用这样的功能，JDK 中必须至少有一个闰秒表。但是：Oracle决定从JDK中删除这些数据。
• 我怀疑你的想法来自阅读Instant的规范，该规范正在谈论时间尺度UTC-SLS(最初是Markus Kuhn的过期提案(。UTC-SLS通过使用橡胶秒概念保持了每天86400秒的虚构。如果你认真对待UTC-SLS，那么你就无法观察到86401秒。注意：UTC-SLS ！= UTC。
• 但是：由于缺少闰秒数据，UTC-SLS 无法在 Java-8 中实现，而只能指定。这实际上意味着，JSR-310团队希望人们将秒解释为UTC-SLS尺度，尽管大多数人在一般考虑秒时肯定不是这个尺度。由于缺少数据，幸运的是，UTC和UTC-SLS之间的这种细微差异在标准Java-8中没有实际意义。我们可以在实践中有效地忽略规范，而只是将Instant处理为与完全忽略闰秒的 POSIX 处于同一比例。同样使用此视图，您只能获得 86400 秒。

<小时 />

如果您仍然想要一个解决方案并且不忽略闰秒，那么在 2015-06-30 上观察 86401 SI 秒的唯一方法是使用像我这样的外部库 (Time4J(：

PlainDate ls = PlainDate.of(2015, 6, 30);
Moment start = ls.atStartOfDay().atUTC();
Moment end = ls.plus(1, CalendarUnit.DAYS).atStartOfDay().atUTC();
System.out.println(SI.SECONDS.between(start, end)); // 86401

Answer 2

在Java中，每天都有相同的秒数。事实上，大多数操作系统不支持闰秒，而是将其视为漂移。 当您设置为UTC时，您实际上已设置为GMT+0