[LEAPSECS] a modest proposal

[Steve Allen]

On Mon 2008-02-11T13:31:17 +0000, Tony Finch hath writ:

> How should the kernel interpret time stamps stored in filesystems? Do you

> propose to retrospectively re-interpret them as being in TI instead of

> POSIX time? (This is related to the problem that Unixes have with FAT

> filesystems that store timestamps in some unspecified local time, which

> implies that the kernel can't be ignorant of local time.)


I suggest that the question of retrospective time stamps is not
interesting, for it is rarely possible to be sure that a system clock
was set "correctly", and it is never possible to convince history to
revise its notion of what time it thought it was (today is George
Washington's birthday, O.S.).

The interoperational scenario of POSIX systems, Windows systems, NTP,
and anything else which is making an effort to maintain filesystem
timestamp synchrony deserves closer analysis.


> How do you cope with programs that assume that POSIX time is UTC, and

> which therefore bypass the tz code when handling UTC timestamps?


My impression is that if TI is internationally endorsed (BIPM has
already indicated openly that if UTC were to abandon leaps they might
consider abandoning TAI) then it is mostly a change in documentation
to say that such codes will henceforth be handling the international
standard TI instead of the other international standard UTC.


> How do you represent TI textually? i.e. how should ISO 8601 be revised?


Given that the ephemerides all started making plain distinction
between time scales starting in the year I was born I'm flabbergasted
to note that ISO 8601 did not already face this issue.
Plainly the IAU's long-time recommendations that the time scale be
explicit belong in ISO 8601.  Until then TI will not be representable.


> How does this affect NTP, which uses a POSIX-like timescale?


My impression was that NTP already has more than enough complexity to
handle the situation.  It already has a monotonic time scale which can
tolerate leaps, but is distinct from any civil or scientific standard
therefore requiring a formatting or conversion to other operational
time scales.

My point in this whole exercise is basically admitting that in a world
of machine-assisted telecommunications the underlying operational time
scale need be monotonic.  In such a world mean solar time is equally
conventional with daylight/summer time shifts.


> Surely its work on the ITRF is still needed for satellite navigation.


Agreed, but somehow I get the impression that will not catch the
attention of legislators and bureaucrats nearly as well as pointing
out that their earth rotation measurements directly affect how they
set their watches.  I expect the IERS would lose a lot of visibility
and political clout without leap seconds.

--
Steve Allen                 <sla at ucolick.org>                WGS-84 (GPS)
UCO/Lick Observatory        Natural Sciences II, Room 165    Lat  +36.99855
University of California    Voice: +1 831 459 3046           Lng -122.06015
Santa Cruz, CA 95064        http://www.ucolick.org/~sla/     Hgt +250 m