Why does the new Java 8 Date Time API not have nanosecond precision? [duplicate]

Question

One of the features of the new Date Time API in Java 8 is supposed to be nanosecond precision. However when I print the current Date Time to the console like so

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

I only see millisecond precision: 2015-11-02T12:33:26,746000000+0100

The operating system does seem to support nanosecond precision. When I print the current date time via the Terminal

date -Ins

I see 2015-11-02T12:33:26,746134417+0100

How do I get nanosecond precision in Java? I'm running Oracle Java 1.8.0_66 on Ubuntu 14.04 64-bit

Fulgurate

Remedied in Java 9. A fresh implementation of Clock captures the current moment in up to nanosecond resolution (depending on the capability of your host hardware clock). – Eastertide

Answer 1

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

Compressed

That last bit is especially important. nanosleep(2) has similar problems on standard, consumer-grade hardware since sleeping for a precise number of nanoseconds entails an error bar of ~1 CPU cycle, which can't really be done in a preemptively multitasked environment. Still, high levels of precision may be useful if you just need to order various events relative to one another and don't care about the precise intervals between them. I'm assuming the clock is monotonically increasing, which I hope is true. – Bactria

Answer 2

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.

Solingen

Is there more information about why second precision does not exist near leap seconds? Is that because there are multiple ways to implement them (e.g. leap smear)? – Deese

@Deese An expression like ChronoUnit.SECONDS.between(instant1, instant2) can never count leap seconds. java.time-designers have decided to hide leap seconds and to pretend that every minute consists of 60 seconds. Their spec officially mandates UTC-SLS, and the real implementation in JDK is de facto like POSIX not like UTC-SLS - simply ignoring leap seconds. All known OS clocks (as base of Clock.systemUTC() behave the same way or apply some kind of clock reset or leap sec smear. SI-secs are not modelled. If you seriously look for true leap sec support then consider my lib Time4J. – Solingen