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

[Gary E. Miller]

Yo Tom!

On Tue, 15 Jan 2019 11:40:07 -0800
"Tom Van Baak" <tvb at LeapSecond.com> wrote:

> But the underlying time_t cannot represent leap seconds, can it?

Yes, and no.  time_t is just seconds since an epoch.  Which epoch
is not well defined.  The epoch may well be anything.  See "man difftime".

time_t dates to the first edition of "Unix Programmer's Manual, November
3, 1971".  No timezone or other basis is given for time_t.  They just
said "system time".  The first leap second was in 1972!  time_t never
caught up.

https://www.bell-labs.com/usr/dmr/www/1stEdman.html

In 1973, just after the third edition, time_t was pegged to GMT.

According to wikipedia, GMT is mean solar time, not UTC.  The seconds
are not the same length, and no leap seconds:

https://en.wikipedia.org/wiki/Greenwich_Mean_Time

Some long time after that the doc changed from GMT to UTC, but the code
did not.  time() returns a time_t which pretends to be UTC, but ignores
leap seconds.  From a current "man time":

"This value is not the same as the actual number of seconds between the
time and the Epoch, because of leap seconds and because system clocks
are not required to be synchronized to a standard reference."

So if you need "real" UTC, POSIX is no help.  And nothing is a help for
future dates since the future leapseconds are unknown.

The only safe way to compute times (to the second) in the past it to do
it yourself using the leapseconds file.

> So how does that gmtime hackery work?

NTPD, or PTP, or something, tells your kernel what the 'real' current
UTC is, including the current leap seconds.  gmtime() just returns that.

NTPD can get the current and past leap second info from the leapseconds
file, from another NTPD, or from a GPS.

> Also, presumably Python is based on POSIX?  Does it use time_t or
> gmtime? Why did Jim's quick Python experiment fail?

Out of my area of understanding.  But I'll guess that like almost every
other time keeping system it is just ignoring leap seconds.  Double
counting the leap second itself as two 59's in a row.  Pretending to be
UTC while actually being an approximation of GMT.

And, yes, during the leap second, all sorts of implementation dependent,
unknown, and unknowable, stuff is happening.

The best bet is to ask the kernel for the current TAI time, and work
with that.  Use the leap seconds file to convert TAI to UTC in your
code.  Or just use TAI for everything.

To add more weirdness, Google, and its NTPD servers, don't use
UTC because they use leap smearing.  And the upcoming GPS week
rollover...

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/9a5eb2ae/attachment.sig>