Date cannot handle leap seconds

[DartBot]

This issue was originally filed by dhasenan@gmail.com

---

http://en.wikipedia.org/wiki/Leap_second

new Date(2008, 12, 31, 17, 59, 60, 0, false)

This yields:

Unhandled exception:
Illegal argument(s):
 0. Function: 'DateImplementation.DateImplementation.' url: 'bootstrap_impl' line:88 col:42
 1. Function: '::main' url: 'file:///usr/local/google/home/dhasenan/dart/tz/timetest.dart' line:4 col:9

The inability to represent leap seconds means that an application could be mistaken about the current time by as much as 25 seconds, presently, and the divergence will only get worse over time.

[sethladd]

cc @floitschG.
Added Area-Library, Library-Dates, Triaged labels.

[floitschG]

Leap seconds are handled by the operating system and are not exposed to client apps. The observed behavior is (until I fix issue #2771) working as intended.

Short summary:
UTC keeps track of leap-seconds. As such one can see things like (from http://www.madore.org/~david/computers/unix-leap-seconds.html):
TAI=2009-01-01T00:00:32.5; UTC=2008-12-31T23:59:59.5; UT1≅2008-12-31T23:59:58.907
TAI=2009-01-01T00:00:33.0; UTC=2008-12-31T23:59:60.0; UT1≅2008-12-31T23:59:59.407
TAI=2009-01-01T00:00:33.5; UTC=2008-12-31T23:59:60.5; UT1≅2008-12-31T23:59:59.907
TAI=2009-01-01T00:00:34.0; UTC=2009-01-01T00:00:00.0; UT1≅2009-01-01T00:00:00.407

However almost all operating systems internally work with (nano/milli)seconds since epoch (2007-01-01). During this mapping (from UTC timestamp to seconds-since-epoch) leap seconds are lost. You can still observe them by time standing still, by skewed times, or by time jumping backwards (or forwards), but that's it.
In any case the OS' seconds-since-epoch hides the leap-second from programs.

According to http://www.ucolick.org/~sla/leapsecs/right+gps.html there are some systems (for example Android) that do not adjust their internal time-value with UTC, but rather with GPS time (no leap-seconds). This means that their would be about 15 seconds off. On my Android I cold not verify this behavior, though (maybe they hacked up the TZ files to deal with the leap-seconds?).

TL;DR: the OS hides leap-seconds and Dart will thus not expose them.

---

cc @lrhn.
Added AsDesigned label.

[DartBot]

This comment was originally written by dhasenan@gmail.com

---

It seems (with a bit of digging) that Linux handles leap seconds by saying that the number of seconds in a minute never changes, but sometimes there is a second that is twice as long as it should be.

This means that interpreting time deltas between 1970 and today would be about 25 seconds' worth of duration off, but the number of seconds would be correct, according to the slightly strange but ultimately pragmatic way Linux has of handling leap seconds.

Similarly, Windows Time service doesn't account for leap seconds. (WTS acts as an NTP client and server. As an intermediate NTP server, it can pass through a leap second value, but it will never generate one as a primary server.) WTS acting as an NTP client will ignore leap second indicators, and it will correct this error at the next synchronization -- in other words, leap seconds are treated as clock drift.

Properly accounting for leap seconds, it seems, is a sufficiently specialized use case, and supporting them a sufficient opening for bugs, that it's probably best not to support them at all (even in the eventual Dart equivalent of jodatime).

[floitschG]

Correct. Only a very minor correction:
time delta since 1970 is ~15 seconds. There have been ~25 leap seconds but afaik 10 of them before 1970.

I think the preferred way to deal with leap-seconds (when this is really necessary) is to set the system time to gps-time (no leap-seconds) and to handle leap-seconds as if it was a daylight saving problem (instead of shifting by 1 hour one would shift by 1 second). This would require using some modified TZ files, but almost all programs should behave consistently.

[DartBot]

This comment was originally written by dhasenan@gmail.com

---

Leap seconds don't work like daylight savings, though. It's a fixed offset of +1 second that applies in perpetuity. I don't see a way to apply leap seconds using the rule system in the Olson database.

Dart doesn't have any reason to do things differently than the OS it's on.

Also, I'm honored that such a frivolous request has resulted in a non-trivial amount of activity.

[floitschG]

I'm no expert in tzfiles, but from what I can read in its man-page http://www.kernel.org/doc/man-pages/online/pages/man5/tzfile.5.html applying fixed perpetual offsets should be possible. However the user would see this offset when looking at the tzoffset value. So you are probably right that this is not the optimal solution either.

Bug-reports like this one are pretty valuable. After double-checking I'm now confident that we are doing the right thing, but I prefer double-checking rather than missing something.