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/[email protected]/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 <[email protected]> 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 _______________________________________________ LEAPSECS mailing list [email protected] https://pairlist6.pair.net/mailman/listinfo/leapsecs
