[ntp:questions] Leap second to be introduced in June

Rob nomail at example.com
Mon Jan 12 16:56:52 UTC 2015

William Unruh <unruh at invalid.ca> wrote:
> So, there are a bunch of proposals. stop the clock a la Mills
> (delivering times that always increase but very very slowly during that
> second). 
> double the rate of the clock during the two seconds around the leap. 
> Have the clock run in TAI and put the leapsecond handling into the
> conversion code. 
> Make the clock run faster, but not twice as fast, during a period around
> the leap second. Are any of these the right thing? 

No, the right thing is to let the clock tick in TAI and not to touch
it, and have the conversion routines handle the changing offset just
like they handle UTC to local time conversion right now.

The conversion code uses a table that gets a new entry every couple of
years, that defines a TAI #seconds where the conversion to human readable
time inserts an extra second.  Just like at certain points in time
it inserts or deletes 3600 seconds to achieve proper local DST.

When the code is suitably advanced, at that leap second moment it can
display a time like 23:59:60.  But that is not really important, it can
display 23:59:59 or 00:00:00 for 2 seconds when that is easier.

What is important is that the leap second is hidden in the conversion,
while the TAI time (in nanoseconds in the case of VMS) just increases
monotonically.   So any applications using it for timestamping and
sequencing don't experience hickups.

Alas, the above design was not chosen in systems like Unix and VMS,
and now the correct behaviour has to be achieved using kludges.

More information about the questions mailing list