[tz] zoneinfo vs zoneinfo-leaps

[Guy Harris]

On Nov 17, 2015, at 7:58 AM, John Haxby <john.haxby at oracle.com> wrote:

> On 16/11/15 22:17, Guy Harris wrote:
>> On Nov 16, 2015, at 2:07 PM, John Haxby <john.haxby at oracle.com> wrote:
>> 
>>>> Also Posix specifically says that there are 86400 seconds in a day, every day, without exception.   It allows for the time 23:59:60
>> It does?
>> 
>> If there are 86400 seconds in every day, then every day begins at 00:00:00 and ends at 23:59:59, which is followed by 00:00:00 of the next day.  No room for 23:59:60 there.
>> 
> 
> It does, and you can have 23:59:60.
> 
> This, obliquely, says that the number of seconds in a day is 86400:
> 
> http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap04.html#tag_04_15
> 
> and this says that there can be 61 seconds in a minute:
> 
> http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/time.h.html

To be precise, what it say is "the ISO C standard was specifically set up to allow UTC-style labels with leap seconds, so we allow that".  (Doug Gwyn pushed for that in the C standard, for precisely that purpose.  C89 and C90 allow for two leap seconds, so tm_sec can go up to 61; C99 only allows for one, so it can go up to 60.)

I.e., mktime() has to be able to be handled a struct tm with tm_sec = 60, although it has to handle it as per

	http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap04.html#tag_04_15

so it has to, for example, treat { .tm_year=115, .tm_mon=5, .tm_mday=30, .tm_hour=23, .tm_min=59, .tm_sec=60 } the same as { .tm_year=115, .tm_mon=6, .tm_mday=1, .tm_hour=0, .tm_min=0, .tm_sec=0 }.

Tue Jun 30 16:59:59 2015

gmtime() and localtime(), however, don't need to ever return it.

> Which is nice. The upshot is that 1435708799 is ambiguous: you can't
> tell whether it was 23:59:59 or 23:59:60 (it was both).

Or, rather, a time_t value of 1435708800 could either be 2015-06-30 23:59:59 UTC or 2015-07-01 00:00:00 UTC.

Sadly, without external information, you can't tell which it is.

> On Linux, adjtimex(2) returns TIME_OOP if you're in the middle of a
> leapsecond so that you can tell the difference between the first and
> second times through 1435708799:

Which is only usable external information if the leap second is in progress.  If you want to know after the fact, well, you're out of luck, and I doubt that any POSIX-compliant gmtime() will return June 30, 2015, 16:59:60 for that value.