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.