问为什么新的Java 8 Date Time API没有纳秒精度？

EN

一般来说，java.time应用编程接口的精度是纳秒级的。例如：

DateTimeFormatter formatter = DateTimeFormatter
    .ofPattern("yyyy-MM-dd'T'HH:mm:ss,nnnnnnnnnZ");
OffsetDateTime odt = OffsetDateTime.of(2015, 11, 2, 12, 38, 0, 123456789, ZoneOffset.UTC);
System.out.println(odt.format(formatter));

输出：

2015-11-02T12:38:00,123456789+0000

然而，它是由OffsetDateTime.now()返回的时钟值，它返回一个只有毫秒的值。

来自Java8中的Clock实现：

这里提供的时钟实现是基于System.currentTimeMillis()的。这种方法很少或根本不能保证时钟的准确性。需要更精确时钟的应用程序必须自己使用不同的外部时钟来实现此抽象类，例如NTP服务器。

因此，这里没有什么不精确的地方--只是使用System.currentTimeMillis()的Clock的默认实现。您可以创建自己的更精确的子类。但是，您应该注意到，添加更多的精度而不添加更多的精度可能并不是非常有用。(诚然，有些时候可能会...)

为了对Jon Skeet的答案做一个重要的补充，Java9应该提供一个改进精度的时钟-参见the bug log。背景:在许多操作系统(特别是Linux)上，有更好的时钟可用。

对于java.time.Clock的JavaSE8规范，

声明：“系统工厂方法提供基于最佳可用时钟的时钟

系统时钟。这可以使用System.currentTimeMillis()，或者更高分辨率的时钟(如果有的话)。

返回的时钟的分辨率是基于System.currentTimeMillis()的，因此只有毫秒级的分辨率。在JDK 9中，实现

基于System.currentTimeMillis()使用的底层本机时钟，提供该时钟可用的最大分辨率。在大多数系统上，这可以是微秒，有时甚至是十分之一微秒。

因此，假设由这些系统工厂方法返回的时钟将始终具有毫秒精度并主动依赖于该时钟的应用程序可能需要更新，以便考虑到更高分辨率的可能性

API文档中所述的。

还应该注意到一个(奇异的)事实，即秒精度不会接近闰秒-甚至在Java9中也不存在。