time : Java Glossary


java.lang.System.currentTimeMillis () will give you the time in milliseconds since 1970 Jan 1 0:00 GMT (Greenwich Mean Time). This is your best bet for computing elapsed times. Freshly minted  java.util.Dateutil.Date objects contain the current GMT date/time stamp as do freshly minted java.util. GregorianCalendar objects. A positive 64-bit long millisecond timestamp will cover 292,271,023 years. A positive 32-bit millisecond timestamp will over only 24 days.
Benchmarking with System.nanoTime System.currentTimeMillis Accuracy Repeating Events
Pentium RDTSC Measuring System.currentTimeMillis Accuracy Learning More
Non-Java Schemes Units of Time Links
Performance Monitoring Mixed Base Conversion

Benchmarking, Measuring Elapsed Time with System.nanoTime

For benchmarking, use System.nanoTime which has much greater resolution than System.currentTimeMillis, but is not synchronized to UTC (Coordinated Universal Time/Temps Universel Coordonné) time in any way. There is no guarantee of resolution. It is not even synchonised between different JVMs (Java Virtual Machines) running on the same machine! I have already heard that you can’t even trust it to be synchronised between threads. All you can count on is that is will not run backwards even when a thread runs on different cores. You may well find every value it returns ends in 000000 because the clock cannot provide better than millisecond resolution/granularity. On a 2 GHz machine, 1 nanosecond represents about two machine cycles or the time at takes to do two additions.

// elapsed time with System.nanoTime
// Works only in JDK 1.5+

long start = System.nanoTime();

// .. do something

// elapsed time in nanoseconds, billionths of a second
long elapsed = System.nanoTime() - start;

On Windows boxes, a 1.5 JVM (Java Virtual Machine) uses the Win32 function QueryPerformanceCounter() which has no defined resolution. It reports clock cycles since bootup. The JVM has to use QueryPerformanceFrequency() to interpret the results. The JVM does this for you and reports the results of System. nanoTime in true nanoseconds. If you want the finer resolution of clock cycles, use the assembler instruction RDTSC (Read Time Stamp Counter). This means that System. nanoTime results are useful both for comparing algorithms on the same hardware and for benchmarking different hardware on the same algorithm.

Unfortunately, if you have multiple CPUs (Central Processing Units) each has its own nanotimer and Windows does not properly keep them synchronised. So you hop back and forth between different timers as your task runs on different CPUs. Linux has ways of dealing with this. Power Management also causes drift between multiple CPUs.

If you have to code for 1.4-, then you can only get millisecond accuracy. You need to use:

// elapsed time with System.currentTimeMillis
// Works in all JDK versions

long start = System.currentTimeMillis();

// .. do something

// elapsed time in microseconds, millionths of a second
long elapsed = System.currentTimeMillis() - start;
Watch the spelling of System.currentTimeMillis(). If you are like me you will be tempted to spell it as System. getCurrentTimeMillis() or System. currentTime InMillis () or System. timeInMillis().

Pentium RDTSC

The Pentium has a hardware instruction RDTSC. It returns the number of clock cycles since the CPU (Central Processing Unit) was powered up or reset. This is subnanonsecond resolution! a 4GHz clock would give you 4 tick counts per nanosecond. This hardware and similar features on other CPU s, is what makes System. nanoTime possible. One nice feature of the counter is that adjusting the time of day clock does not disturb it is any way.

If you are stuck using a JDK (Java Development Kit) 1.4-, then you could roll your own nanoTime method. RDTSC reads the cycle counter into EDX:EAX. Some operating systems may make this a privileged instruction. See Intel’s documentation for more details. You could access them via a bit of JNI (Java Native Interface) with the Pentium class that I wrote and posted the code for. If you use that method, make sure you calibrate so you can discount the considerable overhead of the JNI calls themselves.

Non-Java Timestamp Schemes

There are other timestamp schemes you will run into, e. g. OpenType measures time with 64-bit seconds since 0:00 midnight, 1904-01-01 UTC.

Microsoft timestamps files with 64-bit hundreds of nanoseconds since 1601-01-01 UTC Gregorian. I presume they use Pope Gregory’s flip date to avoid the complication of the missing days. The FileTimes package converts from Java time to Windows native time to access the create date and last access date of a Windows file. In DOS, W3.1, OS2, W95, W98 and Me the dates were kept internally in local time.

Performance Monitoring

You may be interested in performance monitoring. You want to know how much CPU time your program used in various sections as opposed to elapsed time. For this you properly need help from the operating system or a profiler. The CPU is always being used by other tasks, the operating system, or even the system idle loop when you are not using it. You need OS (Operating System) help to avoid counting that time too. In a pinch, you have to add code that marks any time you start/return a call to the OS, so that you can discount that time. That still is not accurate because other tasks will interrupt you at any time and because that scheme would not count the CPU time spent by the OS on your behalf. You can use ThreadMXBean when you are trying to measure individual threads or cores.

System.currentTimeMillis Timer Accuracy

The accuracy of System.currentTimeMillis() varies with platform. It is only nominally accurate to the millisecond, though the actual accuracy/precision/resolution/granularity can be less accurate.
System.currentTimeMillisTimer Accuracy/Precision/Resolution/Granularity
Resolution Platform
55 ms Windows 95/98
10 ms Windows NT, Windows 2000, Windows XP single processor
15.625 ms Windows NT, Windows 2000, Windows XP dual processor
1 or 15.625 ms Vista. 1 only if you sleep between calls to currentTimeMillis. I kid you not.
1 ms Windows 7.
1 ms Mac OS X

Measuring Resolution/Granularity of System.currentMillis

Here is the source code for measuring the resolution of System.currentMillis on your own computer.

In addition, the Thread.sleep method will achieve delays of 1 ms on a single processor and 2 ms minimum on a dual processor.

You can also use the JVMPI (Java Virtual Machine Profiler Interface) for accurate timing.

System.nanoTime() returns the current value of the most precise available system timer, in nanoseconds. It is usually the CPU instruction clock, calibrated and converted into nanoseconds.

Units of Time

Humans use a bizarrely complicated units of measure for time.

Imagine trying to explain this to a space faring species that used but a single unit of measure for time. Java 1.5 added the TimeUnit class to help convert between all these different ways of measuring it.

Unit of Measure Definition
millennium 1000 years, 10 centuries.
century 100 years.
leap year the approximate time with respect to the sun, for the earth to revolve around the sun 366 days.
year the approximate time with respect to the sun, for the earth to revolve around the sun. Sometimes 365 and sometimes 366 days.
season approximately 3 months, ¼ year. Interval between solstice and equinox.
quarter approximately 3 months, ¼ year. Business term for an arbitrary accounting period.
month 28 to 31 days.
fortnight 2 weeks, 14 days.
week 7 days.
day the approximate time for the earth to rotate on its axis. 24 hours. In civil time, the day may be 23 or 25 hours long during daylight saving switch over in jurisdictions that use a 60 minute daylight saving offset. Using 86,400,000 ms for a civil day will get you in trouble spanning daylight saving switch over if you use local time rather than pure UTC.
hour 60 minutes, 1/24 of a day.
minute 60 seconds, 1/60 hour, 1/1440 day. It can occasionally be 59 or 61 seconds long when leap seconds are inserted. Java ignores leap seconds, treating them as physical imperfections of the clocks that are adjusted, but not tracked.
second 1000 milliseconds, 1/60 minute, 1/3600 hour, 1/86,400 day.
millisecond 1000 microseconds, 10-3 seconds, 1/1000 second,1/3,600,000 hour, 1/86,400,000 day.
microsecond 1000 nanoseconds, 10-6 seconds, 1/1,000,000 second, 1/3,600,000,000 hour, 1/86,400,000,000 day.
nanosecond 1000 picoseconds, 10-9 seconds, 1/1,000,000,000 second, 1/3,600,000,000,000 hour, 1/86,400,000,000,000 day.
picosecond 1000 femtoseconds, 10-12 seconds, 1/1,000,000,000,000 second, 1/3,600,000,000,000,000 hour, 1/86,400,000,000,000 day.

Mixed Base Conversion

If you study the code and understand how it works, you should be able to write your own mixed base conversions for hours:minutes:seconds, miles:yards:feet:inches etc.

Repeating Events

If you want a task to be run at some time in the future or repeatedly at regular intervals, you can schedule it with the java.util.Timer class. or also javax.swing.Timer. See Timer for details.

Learning More

Oracle’s Javadoc on currentTimeMillis class : available:
Oracle’s Javadoc on nanoTime class : available:
Oracle’s Javadoc on TimeUnit class : available:
Oracle’s Javadoc on Thread.sleep : available:
Oracle’s Javadoc on ThreadMXBean interface : available:
Oracle’s Javadoc on java.lang.management.MangementFactory.getThreadMXBean() : available:

This page is posted
on the web at:


Optional Replicator mirror
of mindprod.com
on local hard disk J:

Canadian Mind Products
Please the feedback from other visitors, or your own feedback about the site.
Contact Roedy. Please feel free to link to this page without explicit permission.

Your face IP:[]
You are visitor number