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

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 ?!

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

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 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.

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

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 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.

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."

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