Yo Tom! On Tue, 15 Jan 2019 11:40:07 -0800 "Tom Van Baak" <t...@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 g...@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
pgpGNEZTAztr4.pgp
Description: OpenPGP digital signature
_______________________________________________ LEAPSECS mailing list LEAPSECS@leapsecond.com https://pairlist6.pair.net/mailman/listinfo/leapsecs
