REMINDER: LEAP SECOND

Philip Homburg pch-nanog at u-1.phicoh.com
Wed Jun 24 12:22:04 UTC 2015


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




More information about the NANOG mailing list