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

Rob nomail at example.com
Wed Jan 14 08:50:44 UTC 2015


William Unruh <unruh at invalid.ca> wrote:
> That is a translation from seconds to ymdhms. The problem is not there.
> it is in the UTC seconds.
> In UTC one second disappears after the leap second, but not before or
> during. Thus UTC seconds numbering is simply disconinuous (jumps back) .
> And it is that which is the problem, not the common name 
> Thus one has 1435733999 then a second later 1435734000 then .9 seconds
> later 1435734000.9 and .1 seconds later 1435734000.0
>
> It is that discontinuity in the utc seconds that causes the trouble.

No, it is the inadvertent decision to use UTC as a monotonic clock that
causes the trouble.

When you look at the translation from UTC to local time there is a
similar issue, twice a year at the start and end of DST.  However, it
does not cause real trouble because the UTC time ticks continuously
and only the offset used in the translation changes.

Similarly, when the internal computer clock would use TAI and that is
then first translated to UTC using a leap second table and then to
local time using a timezone/DST table, there would be no issue.

Software that needs a mononotonic time would use the raw TAI clock,
software that needs UTC would use the TAI->UTC translated clock, and
end-user software would use the TAI->UTC->localtime translated clock.

It is justifyable that UTC was used, given that there would be much
too much overhead in the conversions using the above method at the time
this decision was made, and the whole "leap seconds" thing was quite
new then anyway.  Also, a computer clock was not as accurate and not
as critical a resource back then.  But still it was this decision that
now causes the problems.



More information about the questions mailing list