[tz] tzdata for 2016 leap seconds

John Haxby john.haxby at oracle.com
Mon Sep 5 10:22:04 UTC 2016

On 02/09/16 17:53, Steve Allen wrote:
> On Fri 2016-09-02T09:41:31 -0700, Paul Eggert hath writ:
>> > whereas I was asking about end-user applications that need
>> > months-in-advance notice of leap seconds. As Bradley writes, most of
>> > the world that cares about leap seconds uses NTP and does not depend
>> > on tz-derived leap seconds information.

> I think anything which handles a leap second is a hack which is
> violating a standard from one agency or another, the implementors are
> not wont to describe that or how they are violating a standard, there
> is inconsistency between implementations, and no generalization
> applies to how the information is being used.

Standards.  Wonderful things, that is, things full of wonder.  Or something.

Posix mandates that there are 86400 seconds in a day while still
allowing struct tm to have its tm_sec field in [0,61).  The rationale
for this seems to be that programmers expect sleep(60) to sleep for a
minute (notwithstanding some implementations waking early).

It wriggles out of the dichotomy by saying that the epoch that time(2)
returns seconds since is only approximately 1970-01-01 and doesn't
require gmtime(3) et al to ever return a value with tm_sec == 60.
Indeed, given that there are exactly 86400s in a day it's not possible
to feed an integer to gmtime(3) et al to get 23:59:60.

As you say, though, Steve, different platforms have different
non-standard ways of dealing with this.  Linux and *BSD's ntp_gettime
will return a specific value if you are in a leap second so a wily
implementation of gmtime_now() can use that to actually return 23:59:60
when it happens and anyone who wants to store that as a timestamp had
better not try to convert it to seconds-since-the-epoch :)


More information about the tz mailing list