[tz] Question about leap seconds

[random832 at fastmail.us]

On Wed, Sep 11, 2013, at 12:36, Paul Eggert wrote:
> No, typically transitions are legally specified in terms of
> local time before the transition.

I meant the actual TIME specified is the second of the transition
(ending :00 typically), not the second before (ending :59 typically),
even when that means that, being specified in terms of local time before
the transition, it names a second in which civil time is not actually
kept with the offset that was used before the transition. We say 2:00,
not 1:59:59.

> I suppose it's theoretically
> possible that an authority currently using some sort of mean time
> could say "we change at 02:00 local time", and this is the start of, or
> in the middle of, a leap second.  Not that the mapping between
> leap seconds and things like BMT are well-defined

Funny, I'd just reached the point of asking about this - my current
description of the data type of tt_gmtoff reads as follows:

OFFSET: A four-byte value representing an offset from UTC. When the
value is evenly divisible by 60, N/60 represents the number of minutes.
When the value is not evenly divisible by 60, the behavior in the
vicinity of leap seconds is unspecified, otherwise N represents the
number of seconds.

I don't have anything better to put there than "unspecified".

I suspect the most reasonable behavior would be to insert the second at
the end of the minute that contains the UTC leap second, e.g.

28 29 30 31 32 .. 58 59 60 00 01 02 03 .. 28 29 30 31 32 --- UTC
58 59 00 01 02 .. 28 29 30 31 32 33 34 .. 59 60 00 01 02 ---
UTC+00:00:30
30 30 30 30 30 .. 30 30 30 31 31 31 31 .. 31 31 30 30 30 --- difference.

I don't know how easy it is to make a closed-form algorithm for this
case, though. Anyone know what the actual behavior of localtime is in
the current code in situations like this? I suspect the leap second code
is terribly under-tested.