Menu
The java function System.currentTimeMillis() apparently returns the number of seconds since 1st January 1970. However, according to wikipedia.org/wiki/Leap_second, since 1972 there have been 25 leap seconds. This means the actual number of seconds since 1st January 1970 has been 25 more than a naive calculation would suggest. Does System.currentTimeMillis() do the naive calculation and ignore the leap seconds?
588
There are three ways to get time in milliseconds in java. 1) Using public long getTime () method of Date class. 3) Java 8 – ZonedDateTime.now ().toInstant ().toEpochMilli () returns current time in milliseconds. 1. Getting current time in Milliseconds
To compute the elapsed time of an operation in seconds in Java, we use the System.currentTimeMillis() method. The java.lang.System.currentTimeMillis() returns the current time in milliseconds. Declaration−The java.lang.System.currentTimeMillis() is declared as follows −
How it does that is a bit of mystery though, since the underlying Instant class spreads the leap second out over the last 1000 seconds of the day - so each of those last seconds will actually be 1.001 seconds long - and your application wont know whether it's in the leap second or not.
The answer is in strict sense: It depends on the underlying operating system. But fact is: All well known operating systems like Windows, Linux, Apple, Android are ignorant towards leap seconds. Instead These operating systems make any clock manipulations at any time (setting back etc., synchronizing with NTP-server...).
I did a small 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, a simple "naive" arithmetics that just regards leap year, but not leap seconds, is used. No extra seconds are added or subtracted.
Update:
Same for the new Instant class:
java> Instant.ofEpochMilli(1000L * 86400 * (365 * 4 + 1) * 12)
java.time.Instant res0 = 2018-01-01T00:00:00Z
POSIX requires that the system clock not admit the existence of leap seconds. MS Windows cannot guarantee the quality (nor existence) of the system clock hardware, and it has eschewed guarantee of 1-second accuracy. Java cannot easily do anything that the underlying system refuses to do. The operating systems are hamstrung by the history of the international regulations that result in one IEEE standard (PTP) that requires leap seconds and another (POSIX) that denies them.
35
Officially, it's up to the OS and implementation - at least for Date. From the docs of java.util.Date:
Although the Date class is intended to reflect coordinated universal time (UTC), it may not do so exactly, depending on the host environment of the Java Virtual Machine. Nearly all modern operating systems assume that 1 day = 24 × 60 × 60 = 86400 seconds in all cases. In UTC, however, about once every year or two there is an extra second, called a "leap second." The leap second is always added as the last second of the day, and always on December 31 or June 30. For example, the last minute of the year 1995 was 61 seconds long, thanks to an added leap second. Most computer clocks are not accurate enough to be able to reflect the leap-second distinction.
I suspect you'll find that although your computer clock is roughly aligned to UTC, that's done via NTP or the like correcting the clock periodically, rather than the OS really implementing leap seconds.
I believe the JRE libraries typically do assume the 86400-second day. It makes life so much simpler, and if you're going to correct for an inaccurate system clock anyway, you might as well correct for leap seconds that way too.
You really want to work out what you're interested in. If you need a way of representing dates and times which use leap seconds, the standard Java libraries may not work well for you. Even JSR-310 no longer supports leap seconds as far as I can tell (which is a very sensible decision for most developers).
35
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With
