REMINDER: LEAP SECOND

Mailman List Mirror (Read Only)
1

In your letter dated Wed, 24 Jun 2015 08:33:14 +0200 you wrote:

Leap years and DST ladjustments have never caused us any major
issues. It seems these code paths are well tested and work fine.

I seem to remember that they were not tested that well on a certain brand of
mobile devices a few years back...

In any case, we can abstract from time zones and DST by using UTC internally
and then converting to local time in the UI.

For UTC the analog approach would be to keep time in TAI internally and
convert to UTC when required.

There is however a big problem with that. UTC as a time scale is not
predictable. There is no way of computing the number of seconds between
2000-01-01 00:00 and 2100-01-01 00:00 because that value is undefined.
The net results is that representing, say, 2020-01-01 00:00 as a TAI
timestamp is impossible until about 6 months before that date.

One way forward for people who for some reason feel attached to representing
the rotation of the earth in civil time is to have a scheme for leap second
just like leap years. For example, insert a leap second every 18 months.

And then revise that scheme once a century to cope unexpect changes in the
earth's rotation.

(Or just get rid of them all together and move to a different time zone every
4000 years).

2

This is much less of a solution than you might hope, because most APIs,
protocols, and data formats require UT. (Usually not UTC but a
representation isomorphic to traditional UT which ignores leap seconds.)

Tony.

3

In your letter dated Wed, 24 Jun 2015 14:05:34 +0100 you wrote:

For UTC the analog approach would be to keep time in TAI internally and
convert to UTC when required.

This is much less of a solution than you might hope, because most APIs,
protocols, and data formats require UT. (Usually not UTC but a
representation isomorphic to traditional UT which ignores leap seconds.)

Supporting legacy formats can be annoying. In some cases it would be no
problem. For example NTP. If there is a defined way to convert between TAI
and UTC then converting TAI to NTP timestamps is easy except during an
actual leap second. Which is not really a problem.

Unix systems would probably need a few new system calls to accept time in TAI.

File formats like tar are unlikely to matter much: find a consistent way of
encoding time around the leap second and most likely nobody will care.

In any case, it would be nice if future formats and systems could have a
sensible time keeping system.