This week's book giveaway is in the OCPJP forum.
We're giving away four copies of OCA/OCP Java SE 7 Programmer I & II Study Guide and have Kathy Sierra & Bert Bates on-line!
See this thread for details.
The moose likes Java in General and the fly likes System.currentTimeMillis() is not UTC in Milliseconds since 1.1.1970 ! Official JavaDoc wrong? Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of OCA/OCP Java SE 7 Programmer I & II Study Guide this week in the OCPJP forum!
JavaRanch » Java Forums » Java » Java in General
Bookmark "System.currentTimeMillis() is not UTC in Milliseconds since 1.1.1970 ! Official JavaDoc wrong?" Watch "System.currentTimeMillis() is not UTC in Milliseconds since 1.1.1970 ! Official JavaDoc wrong?" New topic
Author

System.currentTimeMillis() is not UTC in Milliseconds since 1.1.1970 ! Official JavaDoc wrong?

Sebastian Wagner
Greenhorn

Joined: Oct 14, 2011
Posts: 4

Official JavaDoc Documentation says:

System.currentTimeMillis()

Returns:
the difference, measured in milliseconds, between the current time and midnight, January 1, 1970 UTC.

UTC ?!

Actually it is not UTC ?! System.currentTimeMillis() returns the milliseconds according to the locale settings, so to get the milliseconds from 1.1.1970 in UTC you have to calc the offset of your time zone.

Is that correct ?
Why is it written in the documentation of System.currentTimeMillis that it will return the milliseconds calculated based on UTC if actually it will return it according to the locale ?!

simple example:


Output:
UTC current 1319972018675
UTC offsetInitial 3600000
UTC now Sun Oct 30 10:53:38 CET 2011
Date System.currentTimeMillis() Sun Oct 30 11:53:38 CET 2011
Date current Sun Oct 30 11:53:38 CET 2011

I am living in Berlin timezone, so I got GMT+1 and currently we have summertime.

Why is:
new Date() == new Date(current)
or
new Date() == new Date(System.currentTimeMillis())

Actually System.currentTimeMillis() => returns then the milliseconds in GMT+1 and not UTC ?!

Sebastian

http://code.google.com/p/openmeetings
Sebastian Wagner
Greenhorn

Joined: Oct 14, 2011
Posts: 4

I guess I compare apples with oranges.

The toString method returns the time in the locale timezone.
So what I do here is just wrong...
Winston Gutkowski
Bartender

Joined: Mar 17, 2011
Posts: 8043
    
  22

Sebastian Wagner wrote:I guess I compare apples with oranges...
So what I do here is just wrong...

Good that you found it out for yourself.

<pedantic>

Actually, your original statement ("...it is not UTC...") may be correct, but for a completely different reason than you suppose.

It is because UTC was not actually standardized to its current form until 1972, and therefore the reference point '1/1/1970 00:00:00 UTC' is open to interpretation. The one put on it for computer times is that all days in 1970 and 1971 were exactly the same length, which is certainly good enough for all general purposes, but not necessarily the value that it actually was at the time.

</pedantic>

Winston

Isn't it funny how there's always time and money enough to do it WRONG?
Articles by Winston can be found here
Campbell Ritchie
Sheriff

Joined: Oct 13, 2005
Posts: 39478
    
  28
Winston Gutkowski wrote: . . . all days in 1970 and 1971 were exactly the same length, which is certainly good enough for all general purposes, but not necessarily the value that it actually was at the time. . . .
1st January 1970 to 20th March 1971: 24 hours each.
21st March 1971: 23 hours.
22nd March to 30th October 1971: 24 hours each
31st October 2971: 25 hours.
1st November 1971 to 31st December 1971: 24 hours each.

The same length thing was incorrect, at least in Britain, whence those times come. But the differences do cancel one another out.
Campbell Ritchie
Sheriff

Joined: Oct 13, 2005
Posts: 39478
    
  28
Earlier, I wrote:. . . .
1st January 1970 to 20th March 1971: 24 hours each.
21st March 1971: 23 hours.
22nd March to 30th October 1971: 24 hours each
31st October 2971: 25 hours.
1st November 1971 to 31st December 1971: 24 hours each.

The same length thing was incorrect, at least in Britain, whence those times come. But the differences do cancel one another out.
But was mistaken: these are the correct lengths:
1st January 1970 to 30th October 1971: 24 hours each
31st October 2971: 25 hours.
1st November 1971 to 31st December 1971: 24 hours each.

The differences did cancel one another out.
Winston Gutkowski
Bartender

Joined: Mar 17, 2011
Posts: 8043
    
  22

Campbell Ritchie wrote:1st January 1970 to 20th March 1971: 24 hours each.
21st March 1971: 23 hours.
22nd March to 30th October 1971: 24 hours each...
The same length thing was incorrect, at least in Britain, whence those times come. But the differences do cancel one another out.

Erm, I think we may be talking at cross-purposes here.

You're (I think) referring to Daylight Savings Time, which has absolutely nothing to do with UTC. I'm talking about the standardization of UTC itself.

Winston
Martin Vajsar
Sheriff

Joined: Aug 22, 2010
Posts: 3610
    
  60

If I'm not mistaken, there is yet another deviation from UTC standard. UTC defines "leap seconds" which are used to adjust the time to the irregularities and slight slowing down of Earth's rotation. System.currentTimeMillis refers to the Date class, which says that leap-second tracking is implementation-dependant. Therefore, whether the JVM does or does not follow the UTC specification to the letter is left undefined.

Note that Sun's/Oracle's JVM does not track leap seconds; if it did, many applications might get broken, as there would be minutes consisting of 61 (or possibly 59) seconds. I, for one, rely on hour having exactly 3600 seconds. I'm using JodaTime library to do my time-keeping, by the way, so my app would probably work even on UTC-conforming JVM implementation. Hope I'll never have to find out
Campbell Ritchie
Sheriff

Joined: Oct 13, 2005
Posts: 39478
    
  28
Yes, I think I am at cross-purposes. Sorry.
Winston Gutkowski
Bartender

Joined: Mar 17, 2011
Posts: 8043
    
  22

Martin Vajsar wrote:If I'm not mistaken, there is yet another deviation from UTC standard. UTC defines "leap seconds" which are used to adjust the time to the irregularities and slight slowing down of Earth's rotation.

You are not mistaken, but how you deal with leap-seconds is another matter.

Java uses the same system as most Unix OS's: the 'timer' never registers a 61st second. In the "normal" situation (an extra second in a day), it records two '60th' seconds. In the case of a removed second (hasn't happened yet), it simply doesn't record the 60th second. The nice thing about that is that most applications can then happily assume that every day has exactly 86400 seconds, and the business of jumping back or forward is the responsibility of the timer.

Joda time (well worth a look) does, however, allow leap-seconds to be taken into account in its timestamps and intervals, but this option does slow things down.

Winston
Martin Vajsar
Sheriff

Joined: Aug 22, 2010
Posts: 3610
    
  60

Thanks for the clarification.
Winston Gutkowski wrote:Java uses the same system as most Unix OS's: the 'timer' never registers a 61st second. In the "normal" situation (an extra second in a day), it records two '60th' seconds.

So if I had a leap-second aware JVM implementation, the System.currentTimeInMillis value might get decreased (at the 2nd occurrence of the 60th second). Interesting. However, no great deal, as this might happen as well if someone or something adjusts the computer's clock backwards.

Thanks for pointing out the ability of Joda time to handle leap seconds. I can only hope I'll never need that functionality. Mastering daylight saving time has been hard enough.
Winston Gutkowski
Bartender

Joined: Mar 17, 2011
Posts: 8043
    
  22

Martin Vajsar wrote:So if I had a leap-second aware JVM implementation...

No such animal, as far as I know. And even if there were, I'm pretty sure the behaviour of System.currentTimeMillis() (and thus Date and Calendar and all classes that hang off them) is prescribed.

Winston
Paul Clapham
Bartender

Joined: Oct 14, 2005
Posts: 18708
    
    8

Sebastian Wagner wrote:So what I do here is just wrong...


Yes... as a rule if you find yourself saying "I found this extremely obvious thing which millions of programmers use every day and it doesn't appear to agree with the documentation so it must be a bug in Java", then the answer is always going to be "No, it isn't."
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: System.currentTimeMillis() is not UTC in Milliseconds since 1.1.1970 ! Official JavaDoc wrong?