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

[Gary E. Miller]

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.  :-)

> 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...

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.

> 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.

> > 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.

RGDS
GARY
---------------------------------------------------------------------------
Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703
	gem at rellim.com  Tel:+1 541 382 8588

	    Veritas liberabit vos. -- Quid est veritas?
    "If you can’t measure it, you can’t improve it." - Lord Kelvin
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 851 bytes
Desc: OpenPGP digital signature
URL: <https://pairlist6.pair.net/pipermail/leapsecs/attachments/20190115/3aba5c9a/attachment-0001.sig>