[LEAPSECS] Running on TAI

[Steve Allen]

On Thu 2019-01-17T18:12:25+0100 Martin Burnicki hath writ:
> Hm, maybe that was originally the case. I wonder whether the folks who
> wrote the text just had UTC in mind when they "invented" time_t.

The best insight into the POSIX committee was posted on LEAPSECS in
2003
https://www.mail-archive.com/leapsecs@rom.usno.navy.mil/msg00109.html

Not clear in that posting was that Arthur David Olson's timezone code
for Unix systems already contained the code written by Bradley White
which allows time_t to count every second in the radio broadcast time
scale and handle leap seconds.  POSIX committee members knew that and
decided to disregard it with words that actually prevented system
designers from adopting a more correct scheme.

> So IMO this clearly says that time_t has to be interpreted depending on
> the context, and must not necessarily hold exclusively UTC numbers of
> second.

The tricky part comes when software on one system exchanges values of
time_t with another system that believes time_t has a different value.

> I think a good solution would be to have a structure that contains a
> time_t value plus at least one flag that indicates the leap second
> status, or a field with TAI index. It would be even better to have such
> additional information available with struct timespec, so an application
> can tell if the time stamp is inside a leap second, or not.

I think that the entire infrastructure should recognize the notion of
needing two kinds of time:  precision seconds and civil days.  That is
what the astronomy community had understood and promoted since before
1950.

That is the hard part.  It is the part that technical folks punted on
doing during the 1960s because it would have required explaining the
need for two kinds of time to bureaucrats and legislators and waiting
for them to change laws and regulations.  Instead they chose to act
quickly and implement something controversial and technically barren.

The rest of the technical parts needed for the notion of two kinds of
time have been discussed here before.  The underlying time scale used
for radio broadcasts and operations by any kind of machine should be
purely atomic.  The counting of calendar days and setting of civil
clocks should be calculated using an offset from the underlying atomic
time scale.  The conversions from that underlying atomic time scale
should be widely distributed by a robust scheme like the Domain Name
System and financial transactions, and those conversions should not
happen in critical places like the kernel but in other less-critical
places like libraries for locale and internationalization.

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