Re: [LEAPSECS] leapseconds, converting between GPS time (week, second) and UTC
On 2019-01-18 17:11, Michael H Deckers wrote: .. insert a step of 0.2 s in their time signal about every 71 days. when he meant "about every 77 days". Michael Deckers. ___ LEAPSECS mailing list LEAPSECS@leapsecond.com https://pairlist6.pair.net/mailman/listinfo/leapsecs
Re: [LEAPSECS] Running on TAI
On Fri, Jan 18, 2019 at 1:35 AM Martin Burnicki 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 an
Re: [LEAPSECS] Running on TAI
Tempus fudgit anyone? On 18/01/2019 01:40, Daniel R. Tobias wrote: On 17 Jan 2019 at 15:57, Brooks Harris wrote: In private discussion with one member of that committee on that topic it was said "... but the time people would just not stop arguing!". Funny how everybody knows what time is but can't agree on what time is. The music group Chicago discussed this situation decades ago... https://www.youtube.com/watch?v=7uy0ldI_1HA ___ LEAPSECS mailing list LEAPSECS@leapsecond.com https://pairlist6.pair.net/mailman/listinfo/leapsecs
Re: [LEAPSECS] Running on TAI
Martin Burnicki wrote: > 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. We've got waaay too many time structures already, but if anyone's in a position to standardize new ones and have them taken seriously: a tagged struct timespec, that carries its clock ID along with it, would be huge. ___ LEAPSECS mailing list LEAPSECS@leapsecond.com https://pairlist6.pair.net/mailman/listinfo/leapsecs
Re: [LEAPSECS] Running on TAI
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.burni...@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 ___ LEAPSECS mailing list LEAPSECS@leapsecond.com https://pairlist6.pair.net/mailman/listinfo/leapsecs
