[LEAPSECS] Running on TAI

[Warner Losh]

On Fri, Jan 18, 2019 at 1:35 AM Martin Burnicki <martin.burnicki at meinberg.de>
wrote:

> Steve Allen wrote:
> > 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
>
> Very interesting. Thanks for the pointer!
>

I've had people report similar discussions or histories related from the
committee in real life as well..  :(


> > 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.
>
> Yes, but that's basically what I said: It depends on the context (or
> maybe a different word would be more appropriate than "context"), but
> not on the data type.
>
> It's even the same if you look at different struct timespecs taken on
> the same system, but with different clock IDs. From the data type alone
> you don't know how to interpret this correctly.
>

And that's ultimately my point as well. time_t is defined, by POSIX, only
for certain clocks. All other clocks are aggressively undefined by the
standard. You can't take the time_t's from a timespec returned from any
clock other than CLOCK_REALTIME and be assured of getting meaningful
results for a call to localtime() or gmtime(), for example.
clock_gettime(CLOCK_UPTIME), for example, returns time in an epoch that's
not really knowable (elapsed time since the system booted) without other
dynamic pieces of data.

Hence my comments that time_t is very narrowly standardized, though people
often use it for other things. It's important to constrain arguments about
what POSIX does and does not provide to what is standardized. The whole
leap second fiasco in POSIX revolves around how stupidly it is defined in
the standard (where stupidly here means making the actual time standard
impossible to implement, but also a nasty moral judgement on my part about
how the supposedly "good enough" definition has failed the test of time).


> >> 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.
>
> I fully agree. From what I've read there are some programming
> environments (Java, Python, ...) that provide individual workarounds for
> the limitations of the OS, but I think you run into trouble again if you
> have to exchange timestamped data between applications that have been
> developed using different build environments.
>

Unfortunately, I think that's a rat-hole that's as big or bigger than the
timezone rathole. Data containing times in the past generally isn't in a
uniform timescale used today, so the older you get, the more complicated
things become. And each discipline has differing notions of time.
Astronomers have one, but that differs by observatory if you get old enough
(mostly the same, but all relative to some local time). People have others.
Lots of others. Many notions of local time existed, most loosely based on
the sun, but not exactly Solar Time for all users (eg Big Ben set the time
for the area around it, and other clocks in London were set to Big Ben's
chimes and others to chimes of other clocks set to Big Ben's clocks, so
that you had only a loose notion of a translation to a universal time from
times in historical records). Some stuff would be easy to do, but it grows
quickly as different notions of time would have to be added to accommodate
more users of time throughout history.


> > 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.
>
> I fully agree.
>

I would have killed to have that robust distribution system years ago when
working on the replacement LORAN-C timing system. But that system had crazy
requirements like "we take a spare off the shelf and it has the right UTC
time within a mintue of booting." This spare had a GPS receiver in it, so
unless it had been powered on in the last 6 months, we had no way to do
that because it takes more than a minute to download the GPS almanac to get
the time. And due to security concerns and the remoteness of the stations,
getting this information from the internet, or even any other machine that
might be local to the station, was a non-starter. Had there been a robust,
secure, and standard way to get this information, we could have saved a lot
of hassle...  And yes, I know the "wisdom" of this requirement, but it was
a customer requirement, not ours. And the customer wasn't happy with the
notion of rotating the spares through the system at regular intervals so
they could meet this spec. Thankfully, only the most catastrophic of events
would get the system into this state. I'm not sure if I'm happy or sad all
the LORAN stations with this timing gear have been turned off...

Warner
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://pairlist6.pair.net/pipermail/leapsecs/attachments/20190118/b84d47a1/attachment-0001.html>