Milliseconds in a Java system count seconds in a jump?

Question

The java function System.currentTimeMillis () obviously returns the number of seconds since January 1, 1970. However, according to wikipedia.org/wiki/Leap_second , since 1972 is 25 seconds. This means that the actual number of seconds since January 1, 1970 was 25 more than the naive calculation assumed. Does System.currentTimeMillis () perform a naive calculation and ignore the seconds of the jump?

Answer 1

Officially, it depends on the OS and implementation - at least for Date . From java.util.Date docs:

Although the Date class is designed to display Coordinated Universal Time (UTC), it may not do this exactly, depending on the host environment of the Java virtual machine. Almost all modern operating systems assume that in all cases 1 day = 24 × 60 × 60 = 86400 seconds. In UTC, however, about once a year or two there is an extra second called a “leap second”. The second jump is always added as the last second of the day and is always December 31 or June 30. For example, the last minute of 1995 was 61 seconds, thanks to the added second of the jump. Most computer watches are not accurate enough to reflect the difference in jumps.

I suspect that you will find that although your computer clock is approximately the same as UTC, it is done through NTP or the like, periodically correcting the clock, and not the operating system that actually implements leap seconds.

I believe JRE libraries usually take an 86400 second day. It makes life a lot easier, and if you are still going to fix inaccurate system clocks, you can also edit the jump seconds correctly.

You really want to figure out what interests you. If you need a way to represent dates and times that use leap seconds, the standard Java libraries may not work very well for you. Even the JSR-310 no longer supports second jumps, as far as I can tell (this is a very reasonable solution for most developers).

Answer 2

POSIX requires that the system clock does not allow leap seconds to exist. MS Windows cannot guarantee the quality (or existence) of system clock hardware, and it did not guarantee a 1 second accuracy. Java cannot easily do anything that the underlying system refuses to do. Operating systems are stuck in the history of international regulations that lead to one IEEE standard (PTP), which requires seconds to jump, and another (POSIX), which denies them.

Answer 3

One easy way to check if jump seconds are counted or not is to calculate the number of seconds elapsed since the Epoch at 00:00 on any day of the current year.

If this number of seconds coincides with 00 modulo 60, then the jump seconds are not taken into account, since in 2013 you should have module 25 (to account for the last 25 seconds).

Answer 4

Looking at the Javadoc on currentTimeMillis (), it refers to the documentation of the Date class , which says:

Although the Date class is designed to display Coordinated Universal Time (UTC), it may not do this exactly, depending on the host environment of the Java virtual machine. Almost all modern operating systems assume that in all cases 1 day = 24 × 60 × 60 = 86400 seconds. In UTC, however, about once a year or two there is an extra second called a “leap second”. The second jump is always added as the last second of the day and is always December 31 or June 30. For example, the last minute of 1995 was 61 seconds, thanks to the added second of the jump. Most computer watches are not accurate enough to reflect the difference in jumps.

So, to answer your question: Yes, the jump seconds are counted.

Answer 5

I did a little experiment on javarepl :

 java> new Date(1000L * 86400 * (365 * 4 + 1) * 12) java.util.Date res0 = Mon Jan 01 00:00:00 UTC 2018 

As you can see, simple “naive” arithmetic is used, which simply takes into account a leap year, but not a leap of seconds. No extra seconds are added or subtracted.

Update:

The same goes for the new Instant class:

 java> Instant.ofEpochMilli(1000L * 86400 * (365 * 4 + 1) * 12) java.time.Instant res0 = 2018-01-01T00:00:00Z