为什么新的 Java8日期时间 API 没有纳秒精度?

Java8中新的日期时间 API 的一个特性被认为是纳秒级的精度。但是当我像这样打印当前的日期时间到控制台

DateTimeFormatter formatter = DateTimeFormatter
.ofPattern("yyyy-MM-dd'T'HH:mm:ss,nnnnnnnnnZ");
System.out.println(OffsetDateTime.now().format(formatter));

我只看到毫秒精度: 2015-11-02T12:33:26,746000000 + 0100

操作系统似乎确实支持纳秒级的精度。当我通过终端打印当前的日期时间

date -Ins

我看到2015-11-02 T12:33:26,746134417 + 0100

如何在 Java 中获得纳秒级的精度? 我在 Ubuntu 14.0464位上运行 Oracle Java 1.8.0 _ 66

14123 次浏览

The java.time API in general does have nanosecond precision. For example:

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));

Output:

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

However, it's the clock value returned by OffsetDateTime.now() which is returning a value which only has milliseconds.

From Clock implementation in Java 8:

The clock implementation provided here is based on System.currentTimeMillis(). That method provides little to no guarantee about the accuracy of the clock. Applications requiring a more accurate clock must implement this abstract class themselves using a different external clock, such as an NTP server.

So there's nothing inherently imprecise here - just the default implementation of Clock using System.currentTimeMillis(). You could potentially create your own more precise subclass. However, you should note that adding more precision without adding more accuracy probably isn't terribly useful. (There are times when it might be, admittedly...)

To make an important addition to the answer of Jon Skeet, Java 9 is supposed to deliver a clock in improved precision - see the bug log. Background: On many operating systems (especially Linux), there are better clocks available.

The Java SE 8 specification for java.time.Clock states that "The system factory methods provide clocks based on the best available
system clock. This may use System.currentTimeMillis(), or a higher resolution clock if one is available.". In JDK 8 the implementation
of the clock returned was based on System.currentTimeMillis(), and thus has only a millisecond resolution. In JDK 9, the implementation
is based on the underlying native clock that System.currentTimeMillis() is using, providing the maximum resolution available from that clock. On most systems this can be microseconds, or sometimes even tenth of microseconds.

An application making the assumption that the clock returned by these system factory methods will always have milliseconds precision and actively depends on it, may therefore need to be updated in order to take into account the possibility of a greater resolution, as was
stated in the API documentation.

It should also be noted the (exotic) fact that second precision will not exist near leap seconds - not even in Java 9.