Changes in Instant.now() between java 11 and java 17 in AWS Ubuntu standard 6.0

Question

We are moving to Java 17 (correto17) from Java 11 (correto11). As part of this, we also have to upgrade Ubuntu to standard:6.0 from standard:4.0 in AWS as mentioned here.

We are observing that in Java 11 and Java 17 Instant.now() output is a bit different.

For example,

System.out.println("Instant: " + Instant.now());

is giving output like below

• Java 11 - Instant: 2022-12-12T18:04:27.267229Z
• Java 17 - Instant: 2022-12-12T18:04:27.267229114Z

Can someone let me know what is causing this? How can I make the behaviour same in both the cases?

Protease

Related: twitter.com/indyarni/status/1484193762788184068 – Accelerant

Hasn't Instant always had a precision of nanoseconds? I would expect the difference to be that Instant.now() can now return a value which has a non-zero "submicrosecond" part. – Rizas

In my local Mac (Ventura 13.0.1) OpenJDK Runtime Environment Homebrew (build 17.0.5+0) and openjdk version "17.0.5" 2022-10-18 I am not observing this change. It is returning the value same as in Java 11. Not sure if it is something specific to correta17. – Protease

The format printed is documented and unchanged from Java 11 to Java 17. You need to follow links a couple of steps from Instant.toString() to find it. What is different in your two cases is the value you are printing. The former has zeroes in the last places, which is why they are not printed. – Spectrogram

@OleV.V. Yes that I understood. In corretojava17 there are no extra zeroes and this behaviour is not same across all flavors of OpenJDK 17. For example, OpenJDK Runtime Environment Homebrew (build 17.0.5+0) and openjdk version "17.0.5" 2022-10-18 is also having zeroes in the last place like the way it was in JDK 11. – Protease

On my OpenJDK 18 I get groups of three decimals, for example 2022-12-13T15:13:13.100Z, or 2022-12-13T15:13:13.000000100Z, which I didn’t readily see documented, but may also not be in direct conflict with the documentation, which just states of the fraction of second: As many digits will be output as required. Is this what you are seeing too? And what would your desired output be instead? – Spectrogram

For consistent output use a formatter, for example DateTimeFormatter.ofPattern("uuuu-MM-dd'T'HH:mm:ss.SSSSSSX").withZone(ZoneOffset.UTC).format(Instant.now()). – Spectrogram

Answer 1

Instant#now() obtains the current instant from the system clock. If the system clock returns a precision of only up to microseconds, the Instant#toString simply truncates the last three zeros from the nine digits. If the system on which you are running Java 17 (correto17) returns a precision of nanoseconds, you can truncate it to the precision of microseconds using Instant#truncatedTo(java.time.temporal.TemporalUnit).

public class Main {
    public static void main(String args[]) {
        Instant instant = Instant.now();
        Instant truncatedToMicros = instant.truncatedTo(ChronoUnit.MICROS);
        System.out.println(truncatedToMicros);
    }
}

Learn more about the modern Date-Time API from Trail: Date Time.

Lynching

Is this change specific to correto17? In my local Mac OpenJDK Runtime Environment Homebrew (build 17.0.5+0) and openjdk version "17.0.5" 2022-10-18 I am not observing this change. It is returning the value same as in Java 11. – Protease

This will usually output 6 decimals, for example 2022-12-13T15:19:03.686502Z. Note that if the truncated value happens to fall on a whole millisecond or coarser, fewer digits will be output, for example 2022-12-13T15:20:00Z (observed on OpenJDK 18). – Spectrogram

Answer 2

Yes, and what we need to notice is that when we use MacOS, the time API will just works as 6 digs precision, but when we use Linux(such as Ubuntu), it will be 9 digs : )

Silures

If you are simply adding something to another answer, put it as a comment – Donatist