William Unruh <[email protected]> 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. _______________________________________________ questions mailing list [email protected] http://lists.ntp.org/listinfo/questions
