System.currentTimeMillis

[sri pathi]

Does System.currentTimeMillis() always give you unique values. How does this work?

[Paul Clapham]

Originally posted by sri pathi:
Does System.currentTimeMillis() always give you unique values.

No.

How does this work?

How does what work? The method works the way its documentation says it does. Since calling it twice in the same millisecond causes it to return the same value both times, there's no need to explain why it doesn't do that.

[sri pathi]

Originally posted by Paul Clapham:
How does what work? The method works the way its documentation says it does. Since calling it twice in the same millisecond causes it to return the same value both times, there's no need to explain why it doesn't do that.

I have another question on System.currentTimeMillis. Java API says System.currentTimeMillis returns time in different length according to the OS it runs on. Anybody has any idea of how long it will be on a UNIX machine.

[Paul Clapham]

Originally posted by sri pathi:
Java API says System.currentTimeMillis returns time in different length according to the OS it runs on. Anybody has any idea of how long it will be on a UNIX machine.

That's not what my copy of the API documentation says. It says the granularity of the value may be larger. This means the granularity of the value may be larger than a millisecond.

[Campbell Ritchie]

If you read the API for that currentEtc method, its return value is "long." That means the number of digits will be independent of the "granularity."

[Rob Spoor]

In practice it means that even though in reality two calls can be 5ms apart, System.currentTimeMillis() will still return the same value. I think that for Windows the granularity is either 10 or 20ms.

[Darryl Burke]

On WinXP SP3, I've always got a granularity of 15-16 ms.

[Pat Farrell]

If you want a timer like counter, consider code such as this:

/*
 * TimerSingleton.java
 *
 * Created on October 7, 2006, 8:59 PM
 *
 * Copyright (c) 2006, Pat Farrell. All rights reserved.
 */
 
package com.pfarrell.utils.misc;
 
import java.util.Calendar;
import java.util.Date;
import java.util.TimeZone;
 
/**
 * The  <code>TimerSingleton</code>  class is a simple counter, that 
 * starts at 'now' and goes up. Use it to be sure that we are thread safe.
 *
 * @author pfarrell
 */
public class TimerSingleton {
    /** one and only one */
private static HelperSinglton theHelperSingleton;
 
    /** place to store count */
    private long theCount;
    
    /** Creates a new instance of TimerSingleton */
    private TimerSingleton() {
        Calendar now = Calendar.getInstance(TimeUtils.utcTZ);
        theCount = now.getTimeInMillis();
    }
    /**
     * gets the next value of the counter. If you call it frequently, it will use the incremented
     * count, but if time elapses, it uses the current time
     * @return  the next value of the timer
     */
    public static synchronized Date next() {
        return next(0);
    }
    /**
     * gets the next value of the counter. If you call it frequently, it will use the incremented
     * count, but if time elapses, it uses the current time
     * @param delay millisecond increment
     * @return the next value of the timer
     */
    public static synchronized Date next(int delay) {
        Calendar now = Calendar.getInstance(TimeUtils.utcTZ);
        long tempTime = now.getTimeInMillis() + delay;
        theHelperSingleton.theOne.theCount++;
        if ( theHelperSingleton.theOne.theCount < tempTime) {
             theHelperSingleton.theOne.theCount = tempTime;
        } 
        return new Date(theHelperSingleton.theOne.theCount);
    }
/** class to ensure that the connection is created without Double-checked locking problems */
    static class HelperSinglton {
        static TimerSingleton theOne = new TimerSingleton();
    }    
}

[Harsimran Singh]

Hi Fellows,

I read from Java docs that System.currentTimeMilli(), is the number of milliseconds since the Epoch, way back at midnight, January 1, 1970.
Does it means, As long as you are running an App, and using above function for say name of the file.
Is that means value of the time keeps on increasing? That is, say in year 2020 the value of mili second would be too big? and that will make the file name too ugly?

How actually currentTimeMili works?

[Jeff Verdegan]

Harsimran Singh wrote:Hi Fellows,

I read from Java docs that System.currentTimeMilli(), is the number of milliseconds since the Epoch, way back at midnight, January 1, 1970.
Does it means, As long as you are running an App, and using above function for say name of the file.
Is that means value of the time keeps on increasing?

No. As already pointed out, if you call it twice within the same millisecond, it will be the same. And in fact, most standard PCs have a clock resolution of about 10 ms., so you could call this method thousands or possibly millions times in a row in a tight loop and get the same result every time.

Additionally, if you adjust your system clock backwards, that will cause this method to return a smaller value. (Note that this doesn't happen if you set your computer to just automatically adjust for DST, since all that happens there is your timezone is changing, not the time on your clock.)

How actually currentTimeMili works?

It's implemented as a native method that uses native libraries to access the system clock.

[Jayesh A Lalwani]

If you are just going to append the currenttimeinmillis to the filename without any massaging, it's going to look as ugly in 2020 as in 2012

[Harsimran Singh]

Thanks folks,

Here what I understood, Lets say today I will call the currentTimiMili() and got a value of 1351536912007, a 13 digit long number, So if thats the trend, i.e time diff from 1970, It is possible that I will end up in 30 digit number for or even more in future. (20 to 30 years from now).

Please correct me If I am wrong.

[Paul Clapham]

That's just a matter of simple arithmetic. Here's the basic information you need to answer that question: How many milliseconds are there in a year?

[Paul Clapham]

Or here's another way to look at it. The number you posted is approximately the number of milliseconds in 42 years. So to know what the number is for 63 years, you multiply that number by 1 and a half.

Basic arithmetic like this is a useful skill for a programmer, and since it's routinely taught to 10-year-olds, the skill isn't hard to acquire.

[Bear Bibeault]

If you are looking for a way to generate a unique value, you're looking in the wrong place.

[Jeff Verdegan]

Harsimran Singh wrote:Thanks folks,

Here what I understood, Lets say today I will call the currentTimiMili() and got a value of 1351536912007, a 13 digit long number, So if thats the trend, i.e time diff from 1970, It is possible that I will end up in 30 digit number for or even more in future. (20 to 30 years from now).

Please correct me If I am wrong.

Stop and think about what the number of digits means. It's corresponds to the log of the number. In other words, the power you have to raise 10 to in order to get that number. If A has 1 more digit than B, it's on the order of 10 times as big. If A has 2 more digits than B, then A is on the order of 100 times as big as B.

So, to go from 13 digits to 20 digits, we're adding 7 digits. So if A has 7 digits more than B, then A is on the order of 10^7 times as big (10,000,000 as big) as B. You already know we're measuring time since 1970, and to figure this out it doesn't matter if it's milliseconds, nanoseconds, years, or whatever. The units don't matter here.

All that matters when determining whether you'll go from 13 digits to 20 digits in the next 20 years is this: Is 2032 10,000,000 times as far from 1970 as 2012 is? (Remember, it doesn't matter if we're talking milliseconds, hours, weeks, or centuries here--the answer will be the same regardless.)

[Harsimran Singh]

Hey Guys,

Thanks for your answers, Initially I was thinking that the LONG primitive type can hold only 19 digit number like (9,223,372,036,854,775,807), as from the return type of the method (public static long currentTimeMillis())

So in future, there will be other methods to hold this greater value when time value exceeds 19 digits.

[Paul Clapham]

Yes, that's right. After about 292,000,000 years or so there will be a crisis because System.currentTimeMillis is about to overflow the confines of the "long" data type. I expect somebody will take care of that problem -- I don't plan to worry about it myself.

[Campbell Ritchie]

Harsimran Singh wrote: . . . LONG primitive type can hold only 19 digit number like (9,223,372,036,854,775,807), . . . .

Not LONG, but long. Not 19 decimal digits but 64 binary. It can hold not 9,223,372,036,854,775,807 values, but 18,446,744,073,709,551,616. Half of them are negative, however …

[Jeff Verdegan]

Harsimran Singh wrote:
So in future, there will be other methods to hold this greater value when time value exceeds 19 digits.

Did you stop to think about how long it will take before we need more digits before posting?

[Campbell Ritchie]

That all depends when the Epoch was. Everybody thinks it was 12.00 but I know better. It was 1.00. Because we had summer time (daylight saving time) all winter that year.

[Stuart A. Burkett]

Campbell Ritchie wrote:Everybody thinks it was 12.00 but I know better. It was 1.00. Because we had summer time (daylight saving time) all winter that year.

Actually I think most people believe it was 00.00 GMT (or UTC). That may have been 01.00 in the UK, but in the US it would have still been 1969 and in Australia they would probably have been having lunch.

[Campbell Ritchie]

Stuart A. Burkett wrote:Actually I think most people believe it was 00.00 GMT (or UTC). . . .

Don’t tell those people, but they are right

[Pat Farrell]

You can never get reliable small times from System.currentTimeMillis.

Use a well designed alternative, such as Google Guave Stopwatch. Free, open source, well tested and well documented.