39

Java 8's java.time.Instant stores in "nanosecond resolution", but using Instant.now() only provides millisecond resolution...

Instant instant = Instant.now();
System.out.println(instant);
System.out.println(instant.getNano());

Result...

2013-12-19T18:22:39.639Z
639000000

How can I get an Instant whose value is 'now', but with nanosecond resolution?

user1615355
  • 391
  • 1
  • 3
  • 3
  • It's system architecture dependent (same as Timestamp was) on whether the system supports nanosecond resolution. – Chris Kessel Dec 19 '13 at 18:38
  • 9
    Remedied in Java 9. [A fresh implementation](https://bugs.openjdk.java.net/browse/JDK-8068730) of [`Clock`](https://docs.oracle.com/javase/8/docs/api/java/time/Clock.html) captures the current moment in up to nanosecond resolution (depending on the capability of your host hardware clock). – Basil Bourque Sep 19 '16 at 00:54

5 Answers5

27

You can consider yourself lucky if you get even millisecond resolution.

Instant may model the time to nanosecond precision, but as for the actual resolution, it depends on the underlying OS implementation. On Windows, for example, the resolution is pretty low, on the order of 10 ms.

Compare this with System.nanoTime(), which gives resolution in the microseconds, but doesn't give absolute wall-clock time. Clearly, there is already a tradeoff at work to give you that kind of resolution, still three orders of magnitude short of nanoseconds.

Marko Topolnik
  • 195,646
  • 29
  • 319
  • 436
  • 3
    Accuracy and resolution are hardly synonymous. You can always have much higher resolution that accuracy (or, better, uncertainty). – Ted Hopp Dec 19 '13 at 18:42
  • @TedHopp The correct term to use is *accuracy*. OP's "resolution" is technically termed *precision*. – Marko Topolnik Dec 19 '13 at 18:43
  • 1
    Where did you read that the "technically correct term" for _resolution_ is _accuracy_? The BIPM International Vocabulary of Metrology certainly doesn't take that view. The _resolution_ of a measurement system is typically defined as _"the smallest change it can detect in the quantity that it is measuring."_ This is very different from _precision_ (or _accuracy_, which is not entirely synonymous, but is much more closely related to precision than it is to _resolution_). – Ted Hopp Dec 19 '13 at 18:52
  • @TedHopp Citing [System.nanoTime Javadoc](http://docs.oracle.com/javase/6/docs/api/java/lang/System.html#nanoTime%28%29): "This method provides nanosecond precision, but not necessarily nanosecond accuracy." I'll let you take your dispute to the authors of JDK's Javadoc. – Marko Topolnik Dec 19 '13 at 18:55
  • 2
    Well, I would hardly use the Java docs as the authority for metrology terminology. They perhaps are using _precision_ in the sense of _repeatability_, but it's more likely that they are trying to make the point that reporting time in nanoseconds is a form of [false precision](https://en.wikipedia.org/wiki/False_precision). – Ted Hopp Dec 19 '13 at 19:08
  • 1
    I still fail to see how you get from the Javadoc for `nanoTime` to the idea that _accuracy_ is the technically correct term for _resolution_. Note that the Javadocs changed for Java 7 (and 8) to: "This method provides nanosecond precision, but not necessarily nanosecond resolution (that is, how frequently the value changes)". That is, they dropped the reference to _accuracy_. (In fact, the term _accuracy_ is much more closely related to _precision_ than to _resolution_ -- see the Wikipedia article [_Accuracy and precision_](https://en.wikipedia.org/wiki/Accuracy_and_precision).) – Ted Hopp Dec 19 '13 at 19:26
  • 1
    @TedHopp If you measure 10000 ns where the actual value was 10999 ns, your *accuracy* was at best within 999 ns, whereas your (implied) precision was 1 ns. Therefore accuracy is closely related to resolution and the Javadoc uses the term *accuracy*. If, as you note, the Javadoc has changed, so will my terminology in the future. – Marko Topolnik Dec 19 '13 at 19:38
  • 1
    The 10000/10999 case is a fine example of _false precision_. There's an entire [Wikipedia article on that subject](https://en.wikipedia.org/wiki/False_precision) as well. :) It draws a strong distinction between _precision_ (as a metrology concept) and _significant digits_ (which, when one gets down to it, is what the Javadocs are talking about). – Ted Hopp Dec 19 '13 at 19:49
  • 6
    @TedHopp That distinction just isn't there in the Javadoc, which would be the only place where any kind of precision could be specified. You can either read the Javadoc as "we don't specify any precision for the measurement", "we specify the implied precision of 1 ns", or even "we screwed up by even touching the term *precision*". Take your pick, but I maintain that referring to the terms used in the docs is the best option when writing Java-related answers here. – Marko Topolnik Dec 19 '13 at 19:53
24

While default Java8 clock does not provide nanoseconds resolution, you can combine it with Java ability to measure time differences with nanoseconds resolution, thus creating an actual nanosecond-capable clock.

public class NanoClock extends Clock
{
    private final Clock clock;

    private final long initialNanos;

    private final Instant initialInstant;

    public NanoClock()
    {
        this(Clock.systemUTC());
    }

    public NanoClock(final Clock clock)
    {
        this.clock = clock;
        initialInstant = clock.instant();
        initialNanos = getSystemNanos();
    }

    @Override
    public ZoneId getZone()
    {
        return clock.getZone();
    }

    @Override
    public Instant instant()
    {
        return initialInstant.plusNanos(getSystemNanos() - initialNanos);
    }

    @Override
    public Clock withZone(final ZoneId zone)
    {
        return new NanoClock(clock.withZone(zone));
    }

    private long getSystemNanos()
    {
        return System.nanoTime();
    }
}

Using it is straightforward: just provide extra parameter to Instant.now(), or call Clock.instant() directly:

    final Clock clock = new NanoClock();   
    final Instant instant = Instant.now(clock);
    System.out.println(instant);
    System.out.println(instant.getNano());

Although this solution might work even if you re-create NanoClock instances every time, it's always better to stick with a stored clock initialized early in your code, then used wherever it's needed.

logtwo
  • 502
  • 5
  • 12
  • 7
    `System.nanoTime()` javadoc: `Differences in successive calls that span greater than approximately 292 years (263 nanoseconds) will not correctly compute elapsed time due to numerical overflow.` Looks like I won't be able to use it for my deep space explorer ;) – Adam Dec 19 '17 at 17:45
  • 1
    Yeah, I'm afraid you couldn't. What about designing a CryoNanoClock? Shall we start? – logtwo Dec 19 '17 at 21:01
  • Well, it might not be necessary since Java9 (as per one of the other answers here) is supposed to contain such a clock - but if I was going to design one, I'd keep the last value from `System.nanoTime()` and as soon as the next value is less, reset the clock's variables. – Adam Dec 20 '17 at 12:53
  • 2
    The code is excellent. The premise however is deeply flawed. As has been said in other comments to other answers, precision is not the same as accuracy. This code will violate its contract on just about every piece of hardware on which it runs. – Gabriel Jan 17 '18 at 15:58
  • 1
    https://travis-ci.org/gabrieljones/NanoClock/jobs/330037897#L643 NanoClock.java failing under test as expected. https://github.com/gabrieljones/NanoClock – Gabriel Jan 17 '18 at 19:51
  • 2
    How is this better than returning a random number for nanoseconds, since the nanoseconds don't represent actual time? Seems to me that to make this useful you'd need to synchronize it over the network to some standard clock using NTP or PTP. – Erwin Bolwidt Mar 22 '19 at 03:06
  • I think that `getNano` is not exactly the representation of the Instant. According to javadoc, it "gets the number of nanoseconds, later along the time-line, from the start f the second...". My understanding is that the question was around getting nano precision equivalent of `System.currentTimeMillis()` – vasigorc Apr 09 '19 at 18:37
  • 1
    This implementation will most certainly drift from your official clock over time. One should measure how much it will drift over a period of, say, 2 hours, but it can drift several milliseconds, when compared to a system clock synced over NTP over this period. This inconvenient renders this implementation basically useless, *unless* you periodically update initialInstant and initialNanos, syncing it back to an instant freshly obtained from system. – Leandro Gomide Aug 14 '23 at 16:44
  • 1
    A good point @LeandroGomide, in fact wall clocks drift and are re-synced periodically to a more reliable time source for this reason. This can be incorporated in the initial solution, since detecting significant drifts is indeed easy and can be used to pinpoint need to refresh the reference clock. I will incorporate you suggestions in a revised version of the code, thanks! Of course, this is still relevant for older legacy systems using Java8, in Java9+ there's a better clock as Meno Hochschild said. – logtwo Aug 23 '23 at 12:20
  • 1
    @logtwo I think this code is still relevant in Java 9+, as Java `Instant.now()` or `(Clock.systemUTC().instant())` update frequency can be rather slow in some systems such as Windows, even in Java 9+. One just need to remember to resync is periodically to a more reliable time source. – Leandro Gomide Aug 24 '23 at 19:28
13

So I spent some time digging through the Javadoc here:

http://download.java.net/jdk8/docs/api/java/time/Instant.html

It appears that you should be able to do the following:

Instant inst = Instant.now();
long time = inst.getEpochSecond();
time *= 1000000000L; //convert to nanoseconds
time += inst.getNano(); //the nanoseconds returned by inst.getNano() are the nanoseconds past the second so they need to be added to the epoch second

That said - the other answerers make a good point that it's going to be mighty hard to get an accurate nano-second time as computers just don't typically have the capacity to track time to that resolution

Dave Jarvis
  • 30,436
  • 41
  • 178
  • 315
StormeHawke
  • 5,987
  • 5
  • 45
  • 73
8

You can only get an Instant with "nanoseconds" by using another more precise java.time.Clock by using the Instant-method public static Instant now(Clock clock) In your example the default clock normally uses System.currentTimeMillis() which cannot display any nanoseconds.

Be aware that there is no clock available in nanosecond resolution (real time). The internal nanosecond representation facility of java.time.Instant is mainly due to the requirement to map database timestamps given in nanosecond precision (but normally not accurate to nanoseconds!).

Update from 2015-12-29: Java-9 will deliver a better clock, see my newer post.

Community
  • 1
  • 1
Meno Hochschild
  • 42,708
  • 7
  • 104
  • 126
  • I repeat as far as I know there is no nanosecond resolution clock. But of course you can easily construct a fake clock which pretends to create nanosecond-instants. Just look at the Clock-API. And databases also do similar stuff by inventing nanosecond timestamps (usually by incrementing a counter). – Meno Hochschild Dec 19 '13 at 19:01
0

I needed a high-precision timer common to multiple JVM Instances.

As the Javadoc for System.nanoTime() explicitly states that each JVM is likely to use a different origin for this value, I created the following Test Class which calculates a Nanosecond offset to the Epoch so I can get a Timestamp with the precision of System.nanoTime() but a common origin. (That's basically the same idea proposed in the NanoClock solution posted by @logtwo)

Maybe it helps to visualise the differences in resolution between the values returned by Instant.now() & System.nanoTime() although both nominally have nanosecond precision.

On the Hardware I'm using this may cause deltas of about 1 Millisecond for the origin between JVM's, but that was more than adequate for my purposes.

import java.time.*;
import java.util.concurrent.TimeUnit;

public class EpochNanotimeOffset {

    private static final long NANO_TIME_EPOCH_OFFSET;
    /**/    static {
        final long     systemNanoTime         = System.nanoTime();
        final Instant  now                    = Clock.systemUTC().instant();
        final long     instantNanosSinceEpoch = Duration.between(Instant.EPOCH, now).toNanos();

        NANO_TIME_EPOCH_OFFSET = systemNanoTime - instantNanosSinceEpoch;
    }

    public static void main(final String[] args) throws InterruptedException {
        for (int i=0; i < 99; i++) {

            final long    systemNanoTime          = System.nanoTime();
            final Instant instant                 = Clock.systemUTC().instant();
            final long    instantNanos            = Duration.between(Instant.EPOCH, instant).toNanos();
            final long    correctedSystemNanoTime = systemNanoTime - NANO_TIME_EPOCH_OFFSET;
            final long    deltaNanos              = instantNanos   - correctedSystemNanoTime;

            Duration.between(Instant.EPOCH, instant).toNanos();

            System.out.print  (                  "OffsetNS=" + NANO_TIME_EPOCH_OFFSET );
            System.out.print  ('\t' + "instantNSsinceEpoch=" + instantNanos );
            System.out.print  ('\t' +   "correctedSystemNS=" + correctedSystemNanoTime );
            System.out.print  ('\t' +            "systemNS=" + systemNanoTime );
            System.out.println('\t' +             "deltaNS=" + deltaNanos );

//          TimeUnit.SECONDS.sleep(3);
        }
    }
}
Dave The Dane
  • 650
  • 1
  • 7
  • 18
  • Resolution note: Running that on a 64-bit Windows 10 Laptop with an Intel Core i5-8350U Processor, the resolution of the Nanoseconds in Instant was almost exactly 1 Millisecond (using Oracle JDK 16 & openJDK 16). Running on our Linux development server with a Xeon E5-2660 processor & openJDK 16, the resolution was truly nanosecond. – Dave The Dane Apr 09 '21 at 08:16