On 16 Nov 2015, at 21:42, Random832 <random832@fastmail.com> wrote:

Ken Murchison <murch@andrew.cmu.edu <mailto:murch@andrew.cmu.edu>> writes:

...

Having studied up the tzfile(5) format and written some code to produce these files, I'm wondering why the files in zoneinfo-leaps include the leap records AND adjust the transition times by the appropriate number of leap seconds. This seems redundant to me. If the file includes the leap second records, why not let the consumer adjust the transitions?

Because the values are meant to be time_t timestamps, and for these files they're intended for a notional system in whose time_t 946684822 rather than 946684800 represents a date of 2000-01-01 00:00:00 UTC..

As I’m sure a good many people reading this are aware … Also Posix specifically says that there are 86400 seconds in a day, every day, without exception. It allows for the time 23:59:60 by saying that the time in seconds is /approximately/ the time since midnight at the start of 1970 … It’s a mess, but it’s a well-intentioned mess. t + 86400 is this time tomorrow. For those few people who are prepared to do arithmetic “properly” (tomorrow might be t + 86399 or t + 86401) the timezone files including leap seconds are available. That’s not a posix system though … you pays your money, you takes your choice. jch

On Nov 16, 2015, at 2:07 PM, John Haxby <john.haxby@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.

by saying that the time in seconds is /approximately/ the time since midnight at the start of 1970 …

It’s a mess, but it’s a well-intentioned mess. t + 86400 is this time tomorrow. For those few people who are prepared to do arithmetic “properly” (tomorrow might be t + 86399 or t + 86401)

Where "properly" means "break the time_t down into year/month/day/hour/minute/second, add 1 to the day, carry into the month if that makes the day number bigger than the number of days in the month in question, carry into the year if carrying into the month makes it go from 11 to 12, and then convert that back into a time_t".

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

On 16/11/15 22:17, Guy Harris wrote:

...

On Nov 16, 2015, at 2:07 PM, John Haxby <john.haxby@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_...

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

On Mon, Nov 16, 2015 at 11:20 PM, Random832 <random832@fastmail.com> wrote:

Bradley White <bww@acm.org> writes:

...

Because ...

You also need the leap records to determine the magnitude of the tm_sec field during leaps (see the "hit" variable, which probably shouldn't be a bool BTW).

I think the question was the opposite - not why the leap records exist, but why they're not the _only_ difference between a leap tzfile and a non-leap one.

That may be a possibility, but in general it is preferable to do things at zic time over tzfile read time.