A DESCRIPTION OF THE REQUEST :
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.
JUSTIFICATION :
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.
EXPECTED VERSUS ACTUAL BEHAVIOR :
EXPECTED -
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:
http://juliusdavies.ca/nanotime/
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)
linux-x86
mac-x86
solaris-sparc
win32
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:
http://juliusdavies.ca/nanotime/src/native/mac_nano.c
http://juliusdavies.ca/nanotime/src/native/unix_nano.c
http://juliusdavies.ca/nanotime/src/native/win_nano.c
---------- END SOURCE ----------
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.
JUSTIFICATION :
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.
EXPECTED VERSUS ACTUAL BEHAVIOR :
EXPECTED -
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:
http://juliusdavies.ca/nanotime/
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)
linux-x86
mac-x86
solaris-sparc
win32
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:
http://juliusdavies.ca/nanotime/src/native/mac_nano.c
http://juliusdavies.ca/nanotime/src/native/unix_nano.c
http://juliusdavies.ca/nanotime/src/native/win_nano.c
---------- END SOURCE ----------
- relates to
-
JDK-8242504 Enhance the system clock to nanosecond precision
- Resolved
-
JDK-8185891 System.currentTimeMillis() is slow on Linux, especially with the HPET time source
- Closed