JDK-6709908 : System.currentTimeNanos() to support nanosecond precision
  • Type: Enhancement
  • Component: core-libs
  • Sub-Component: java.lang
  • Affected Version: 7
  • Priority: P5
  • Status: Closed
  • Resolution: Not an Issue
  • OS: windows_xp
  • CPU: x86
  • Submitted: 2008-06-03
  • Updated: 2017-07-20
  • Resolved: 2017-07-20
JSR 310 (Public Project for the Date and Time API) will introduce a javax.time.Clock.system() call that can support nanosecond precision.

Introducing java.lang.System.currentTimeNanos() that returns a two-element long array containing {seconds, nanos} since epoch would go together well with JSR-310.

Solaris and Linux already support nanosecond precision thanks to clock_gettime(CLOCK_REALTIME).  System.currentTimeMillis() already uses that, but it would be nice to not truncate the nanoseconds.  The situation on Mac OSX is not as good, since only gettimeofday() is available, which gives microseconds.  But it's still an improvement.

Of course on Windows all timing information between the 10ms granularity is quasi-fictional, but for figuring out order-of-events in a log, a "high-resolution clock simulator" on windows would still be useful.

System.currentTimeNanos() would return a two-element long array containing {seconds, nanos} since epoch.  The time returned would be as accurate as the operating system could provide (e.g. nanos would be micros * 1000 on Mac OSX).

On Windows the time returned would be an approximation, since Windows cannot accurately report time changes faster than 10ms apart.

---------- BEGIN SOURCE ----------
Here is a prototype java library which illustrates the idea:


Download "nanotime.jar" and type:

java -jar nanotime.jar

It will print out 1 timing using System.currentTimeMillis(), and 10 timings using something like currentTimeNanos():

2008-05-14/17:08:15.940000000/PDT JavaTime
2008-05-14/17:08:15.940787900/PDT NativeTime
2008-05-14/17:08:15.943128363/PDT NativeTime
2008-05-14/17:08:15.943134021/PDT NativeTime
2008-05-14/17:08:15.943138875/PDT NativeTime
2008-05-14/17:08:15.943149498/PDT NativeTime
2008-05-14/17:08:15.943154580/PDT NativeTime
2008-05-14/17:08:15.943158845/PDT NativeTime
2008-05-14/17:08:15.943163060/PDT NativeTime
2008-05-14/17:08:15.943167074/PDT NativeTime
2008-05-14/17:08:15.943171148/PDT NativeTime

At this time the jar file can be run on Java 1.3, 1.4, 5, 6 on the following platforms:

linux-amd64 (includes intel 64bit x86, too)
linux-ppc (IBM's JDK)

You need write-permission to ${user.home} to run this jar file.  It automatically extracts a native library to ${user.home}/.libjnt/ for the current platform.

Here is the JNI C code that asks the Operating System for the current time:


---------- END SOURCE ----------

JSR-310 was integrated in Java 8. It provides java.time.Instant.now() which returns an Instant containing seconds since epoch and nanosecond-of-second. It already has methods for time comparison, arithmetic, conversion, etc. and is thus preferable to an API that returns a bare array of these values. Closing as Not an Issue.

EVALUATION The current request seems to be a more simple suggestion of exposing clock_gettime(CLOCK_REALTIME,...) through this new method. This does have high-resolution on modern Linux and Solaris systems - a few microseconds. But older Linuxes (and possibly Solaris) and Windows would still be limited to a value updated ~10ms. I don't see a reason to return an array however as a long can hold enough nanoseconds to represent 292+ years. The method would have to be fairly loosely specified to accommodate platform differences. We also don't know how well clock_gettime tracks TOD changes (ntp, DST etc), or how well behaved it is on MP systems.

EVALUATION Unformtunately no conclusion was reached about what the actual requirements were for a function like currentTimeNanos().

EVALUATION A discussion of this presise question may be found here: http://www.nabble.com/High-resolution-timers-and-JSR-310-td17302683.html David Holmes' response from May 18, 2008; 03:04pm is particularly enlightening. Also worth reading are the following two bugs: 6380553 provide precise SystemCurrentTimeMillis() based on System.nanoTime() 6298653 Use finest granularity clock (System.nanoTime) for sleep, wait, util.Timer ...