[LEAPSECS] leap seconds in POSIX

[Warner Losh]

On Sat, Feb 1, 2020 at 3:39 PM Brooks Harris <brooks at edlmax.com> 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
> > LEAPSECS at leapsecond.com
> > https://pairlist6.pair.net/mailman/listinfo/leapsecs
> >
> >
>
> _______________________________________________
> LEAPSECS mailing list
> LEAPSECS at leapsecond.com
> https://pairlist6.pair.net/mailman/listinfo/leapsecs
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://pairlist6.pair.net/pipermail/leapsecs/attachments/20200201/e382bb29/attachment.html>