On Sat, Feb 1, 2020 at 3:39 PM Brooks Harris <[email protected]> wrote:
> > (As I understand it time_t is deprecated and replaced by struct timespec > in modern POSIX systems. This does not eliminate the leap-second > difficulty.) > Kinda sorta... the timespec struct has a time_t inside of it. > The leap-second modification of the Gregorian calendar YMDhms counting > sequence presents an irreconcilable dilemma. I think most appropriate > term to describe the UTC v.s. computer time and civil time mismatch is > "incommensurate". You cannot map UTC into Gregorian without losing > something, and that something is the leap-second. > The problem is that it has an irregular radix. :60 is the odd-duck whose quacks are the harbingers of doom :) > As Tom points out, the definition of the POSIX origin, "The Epoch", is > *intentionally* vague to accommodate systems that could not accurately > align to "1970-01-01 00:00:00". This date and time is said to be "UTC" > but this is misleading as it is not strictly UTC because A) the count > skips leap-seconds and B) UTC was not an integral second adjustment > until 1972-01-01 00:00:10 (TAI) = 1972-01-01 00:00:00 (UTC) (I like to > call this alignment point UTC1972), so the POSIX "the Epoch", > 1972-01-01 00:00:00 (POSIX), sits in the never-never world before > UTC1972. As I understand it modern systems try to align "the Epoch" at > exactly 63072000s (730 86400s days) before UTC1972. > That's because every POSIX day is 86400 seconds long, without exception. :) :< POSIX doesn't define the relationship between time_t and anything else, other than to prescribe a mapping. Many systems these days have a specification that like "Number of actual seconds since UTC1972+63072000 + negative leap seconds - positive leap seconds." to align the time scales to time_t. But the problem with time_t are legend. I should do a talk that lists them all. The biggest problem is that people think they can solve the timestamp issue with metadata. But you can't because that metadata necessarily must be discarded to fit within external protocol requirements. If I do an NFS get file attributes, one attribute is file creation time. Should this occur during a leap second, there's no way to encode that metadata in response to that request. That's even assuming the stable media encodes things such that it is knowable, or that the OS provides a way to set that time, or that the OS ticks through the leap second properly. And as brooks said, you can't fit 86401 pegs into 86400 holes. One hole necessarily must hold two pegs. Smearing breaks frequency, and accepts an offset to try to power through the problem, but it in no way solves the problem... it just accepts certain errors as OK to paper over the whole mess. And even if all that were right, it assumes you can get a verified, temper-proof list of leap seconds easily, which isn't always possible. It's the cross product of all these issues that make leap seconds an impossible problem to solve in a way that doesn't discard data of some sort... Warner > > > > > > On 1/27/2020 12:59 AM, Hal Murray wrote: > >> Does anybody know of a good writeup of how to fix POSIX to know about > >> leap > >> seconds and/or why POSIX hasn't done anything about it yet? > >> > >> I assume the basic idea would be something like switch the kernel to > >> use TAI > >> rather than UTC and implement conversion in some library routines. > >> > >> > >> There is a discussion on the IETF ntp list with typical S/N for this > >> topic. > >> > > > > _______________________________________________ > > LEAPSECS mailing list > > [email protected] > > https://pairlist6.pair.net/mailman/listinfo/leapsecs > > > > > > _______________________________________________ > LEAPSECS mailing list > [email protected] > https://pairlist6.pair.net/mailman/listinfo/leapsecs >
_______________________________________________ LEAPSECS mailing list [email protected] https://pairlist6.pair.net/mailman/listinfo/leapsecs
