[LEAPSECS] Meeting with Wayne Whyte

[Stephen Colebourne]

On 31 January 2011 19:57, Steve Allen <sla at ucolick.org> wrote:

> In that is the nugget of how leap seconds are no different

> announcements that the daylight/summer time zones transition will

> happen at some date other than the previous schedule.

> (e.g., due to some sports event like the 2000 Olypmics and the 2006

> Commonwealth Games in Australia, or any of the other excuses that

> bureaucrats have used when they say you'll have to update your

> zoneinfo files.)

>

> Leap seconds are just conventional adjustments (to an underlying

> presumed-adequately-uniform time scale) which are decreed by human

> authorities to be implemented at times which are deemed most

> convenient.  They are entirely compatible with the POSIX rules as

> implemented by the zoneinfo scheme.


I disagree, based on experience of implementing both time zones and
leap seconds.

Time zones are about the gaps and overlaps in the local timeline
relative to the standard timeline. Times are repeated during an
overlap, but no fundamentally new time representations are created.
Jumping from 01:00 to 02:00, or overlapping from 02:00 back to 01:00,
the second still runs from 0 to 59 inclusive.

By comparison, leap seconds add a new time representation 23::59:60
which exists in no other way. Its the creation of the new time that is
problematic.

Suggesting that zoneinfo could be used to manage an overlap of the
last second (23:59:59 repeats) doesn't work either, because there is
no way to determine whether it is the first or second time around
using the offset. With time zones, the difference between the first
and second times can be determined due to the different offsets. (Time
zones are correctly modelled as rules for when the offset changes,
leap seconds don't change the offset so cannot use the time zone
model)

Basically, the software design needed to manage zoneinfo and time
zones is entirely different to that needed to solve the leap second
case.

Stephen