[LEAPSECS] leapseconds, converting between GPS time (week, second) and UTC

[Warner Losh]

On Tue, Jan 15, 2019 at 1:50 PM Gary E. Miller <gem at rellim.com> wrote:

> Yo Warner!
>
> On Tue, 15 Jan 2019 12:43:46 -0700
> Warner Losh <imp at bsdimp.com> wrote:
>
> > Except that's not a leap second. struct tm doesn't do leap seconds
> > really. It kinda sorta does, but it kinda sorts doesn't.
>
> Well, it does in a modern Linux kernel.  Otherwise NTPD would fail
> on the leap second, and that only happens every year so.  :-)
>

You are wrong. The kernel doesn't use struct tm. The kernel does this by
ticking either in TAI or by incrementing a TAI offset. ntpd uses a
different interface that exposes these things to it so it can broadcast the
leap second indicators correctly.


> > First, when you convert back and forth to time_t, you lose leap second
> > information. It's impossible to convert back and forth from at least
> > the UTC time zone. There's some 'right' time zones, but they aren't
> > strictly speaking POSIX compliant because it uses the wrong math.
> > Non-conforming, but damned useful and not wrong.
>
> Which is why you can't use time_t in UTC,  but time_t in TAI
> can work, as well as struct tm, usually.  Lot's of latent bugs...
>

No. time_t is not TAI or GPS. It is UTC. Adjusted UTC. It is the number of
SI seconds since 1970, minus all the positive leap seconds, plus all the
negative ones.

Now, you can use that type bogusly to hold any count from any epoch with
any rules you like, but such use is not POSIX conforming. Many people abuse
time_t to store TAI, it's true, but that's not its definition, and you'll
wind up confusing things because of the 40 second offset between the two.


> If you squint at it, GPS time (gps weeks, time of week) is just another
> notation very similar to time.  And we know that works.
>

GPS time has no leap seconds. It's a monotonic count since 1980.


> > Second, many of the tm_xxxx fields can create a time that's N xxxx's
> > in the future by adding N to that structure and converting. So tm_sec
> > == 60 could be a leap second, or it could be the second after tm_sec
> > == 59.
>
> Since future leap seconds are unknown, and unknowable, there is no
> possible valid way to do this on the time scale of years.
>

Correct. This is the fundamental flaw of UTC.


> > > But gpsd and ntpd try real hard to be correct.  Sadly, with leap
> > > smear, there is no consensus on what is 'correct'.
> > >
> >
> > Both leap seconds and leap second smear must die. Others have
> > different opinions, some strongly held. Not all the contradictory
> > opinions are necessarily wrong.
>
> Good luck with that.
>

Yea. Having done timing systems for a decade now a decade ago, I always
felt that was the best solution. The BIH guys broke time by trying to fix
it. :(

Warner
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://pairlist6.pair.net/pipermail/leapsecs/attachments/20190115/21d02fb4/attachment-0001.html>