Markus Kuhn wrote:
> A new Internet-Draft with implementation guidelines on how to handle UTC
> leap seconds in Internet protocols was posted today on the IETF web
> site:
>
> "Coordinated Universal Time with Smoothed Leap Seconds (UTC-SLS)",
> Markus Kuhn, 18-Jan-06. (36752 bytes)
>
> http://www.ietf.org/internet-drafts/draft-kuhn-leapsecond-00.txt
Accepting that UTC-SLS is not the right choice for some applications
and that operating system APIs should be very clear on what timescales
are being served up in different cases, I think UTC-SLS is a valuable
contribution and a good choice for the default timescale for quite
a lot of systems. In particular, it would be a good substitute in
current APIs which claim to return UTC but actually don't handle
leap seconds.
Appendix A argues against putting the adjustment interval after the
leap second (method 4a) by pointing out that some time signals contain
announcements of the leap second before it happens but not after.
I think a stronger argument against this method of adjustment is that
during positive leap seconds UTC and UTC-SLS would be indicating
different dates:
UTC UTC-SLS(A.4a)
2005-12-31 23:59:58 2005-12-31 23:59:58
2005-12-31 23:59:59 2005-12-31 23:59:59
2005-12-31 23:59:60 2006-01-01 00:00:00
2006-01-01 00:00:00 2006-01-01 00:00:00.999
2006-01-01 00:00:01 2006-01-01 00:00:01.998
(Exact fractional times depending on whether the correction interval
starts at the start or the end of the leap second).
This is a pity, in my opinion, because I think it would be nice to
leave open at least the option of implementing UTC-SLS as simply
"steer your clock towards UTC at the rate of 1ms per second"
though I understand that that wouldn't be the right choice in many
cases.
Ed.
Received on Thu Jan 19 2006 - 03:47:51 PST