[LEAPSECS] Running on TAI

[Martin Burnicki]

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!

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

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

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


Martin
-- 
Martin Burnicki

Senior Software Engineer

MEINBERG Funkuhren GmbH & Co. KG
Email: martin.burnicki at meinberg.de
Phone: +49 5281 9309-414
Linkedin: https://www.linkedin.com/in/martinburnicki/

Lange Wand 9, 31812 Bad Pyrmont, Germany
Amtsgericht Hannover 17HRA 100322
Geschäftsführer/Managing Directors: Günter Meinberg, Werner Meinberg,
Andre Hartmann, Heiko Gerstung
Websites: https://www.meinberg.de  https://www.meinbergglobal.com
Training: https://www.meinberg.academy