- From: Graham Klyne <GK-lists@ninebynine.org>
- Date: Wed, 17 Nov 2004 09:34:35 +0000
- To: Russ Housley <housley@vigilsec.com>, Harald Tveit Alvestrand <harald@alvestrand.no>, Simon Leinen <simon@limmat.switch.ch>, Pete Resnick <presnick@qualcomm.com>
All, [I'm bcc'ing this to www-archive@w3.org to ensure there is a public copy of this message that can also be cited as a web reference, as this discussion has moved off the IETF mailing list. This is implicitly permission to use the message in public debate if you so choose.] I'm not convinced that changing one word in the spec really addresses this problem. I don't think there's a big problem with this as an *experimental* protocol, but I remain concerned about the uncertainty of leap second handling if this is to become a full standard. The problem with simply "ignoring" or "excluding" leap seconds I see is that, depending upon where you start from, different results can be obtained. The problems are in the relationship between date/time values and time intervals, where the expression of date/time is in the form of an interval from a fixed datum. By "ignoring" or "excluding" leap seconds, do you mean: (a) that all days are assumed to be exactly 24*60*60 seconds long, and that a date can be derived from a timestamp by division to obtain a day number, followed by conversion to date form using standard algorithms, or (b) that the specified number of seconds from the datum time is assumed to be exactly as specified, without making any adjustment for leap seconds. (This is what I thought was meant by "ignored", though apparently I was wrong. Saying "excluded" gives me less basis to decide which is meant.) The problem with (a) is that, over time, the binary timestamp for this specification gets out of phase with the equivalent value for TAI (or whatever the current accepted time measurement standard may be). Assuming that system times are synchronized, more or less, with the official time then timestamps become difficult to generate or just incorrect. The problem with (b) is the complexity of taking leap seconds into account when converting between timestamp and date/time values. Indeed, there is no way to determine an accurate date-and-time value for future values of the timestamp, because of lack of knowledge of (distant-)future leap seconds (but, as proposed in RFC3339, a timestamping application probably doesn't need to care too much about future dates). So, for the time being, I suggest that the editorial fix needs to be quite clear about which of these options ((a) or (b)) is intended. I think (b) is the rational choice. I'd also suggest that the text points out that a simple conversion between dates and timestamps (based on 24*60*60) will yield results that are inaccurate by some unspecified number of seconds. For the future, when the spec is further evaluated, my suggestion would be to use a pair of numbers, corresponding to (day number, second number). Applications that don't care about leap seconds can be kept simple, and most applications are able to obtain consistent results, to the extent that they do or do not care about leap seconds. My views are discussed at greater length, with opposing views arguing that a single value per (b) above is preferred, on the Haskell libraries mailing list [1][2] (cited in my original message, repeated here for convenience). ... I also tried to track down the text suggested by Pete Resnick, but I wasn't certain which text from RFC1305 was being proposed, but I think it may have been this: [[ The NTP Timescale and Reckoning with UTC The NTP timescale is based on the UTC timescale, but not necessarily always coincident with it. At 0h on 1 January 1972 (MJD 41,317.0), the first tick of the UTC Era, the NTP clock was set to 2,272,060,800, representing the number of standard seconds since 0h on 1 January 1900 (MJD 15,020.0). The insertion of leap seconds in UTC and subsequently into NTP does not affect the UTC or NTP oscillator, only the conversion to conventional civil UTC time. However, since the only institutional memory available to NTP are the UTC timecode broadcast services, the NTP timescale is in effect reset to UTC as each timecode is received. Thus, when a leap second is inserted in UTC and subsequently in NTP, knowledge of all previous leap seconds is lost. Another way to describe this is to say there are as many NTP timescales as historic leap seconds. In effect, a new timescale is established after each new leap second. Thus, all previous leap seconds, not to mention the apparent origin of the timescale itself, lurch backward one second as each new timescale is established. If a clock synchronized to NTP in 1990 was used to establish the UTC epoch of an event that occurred in early 1972 without correction, the event would appear fifteen seconds late relative to UTC. However, NTP primary time servers resolve the epoch using the broadcast timecode, so that the NTP clock is set to the broadcast value on the current timescale. As a result, for the most precise determination of epoch relative to the historic UTC clock, the user must subtract from the apparent NTP epoch the offsets shown in Table 8 at the relative epoches shown. This is a feature of almost all present day time-distribution mechanisms. ]] -- RFC1305, appendix E I also noticed this, which adds a little support to my suggested approach: [[ It is possible that individual systems may use internal data formats other than the NTP timestamp format, which is represented in seconds to a precision of about 200 picoseconds; however, a persuasive argument exists to use a two-part representation, one part for whole days (MJD or some fixed offset from it) and the other for the seconds (or some scaled value, such as milliseconds). This not only facilitates conversion between NTP and conventional civil time, but makes the insertion of leap seconds much easier. All that is required is to change the modulus of the seconds counter, which on overflow increments the day counter. This design insures that continuity of the timescale is assured, even if outside synchronization is lost before, during or after leap-second insertion. Since timestamp data are unaffected, synchronization is assured, even if timestamp data are in flight at the instant and originated before or at that instant. ]] -- RFC1305, appendix E, final para. #g -- [1] Approximate locus of Haskell library discussion: http://www.haskell.org/pipermail/libraries/2003-June/001093.html http://www.haskell.org/pipermail/libraries/2003-June/001157.html [2] Pretty much my own current view in that debate... http://www.haskell.org/pipermail/libraries/2003-June/001211.html http://www.haskell.org/pipermail/libraries/2003-November/001541.html (but there are other views "nearby") At 08:07 16/11/04 -0500, Russ Housley wrote: >I am fine with "excluding". Who should send the note to the RFC Editor? > >Russ > >At 11:02 PM 11/15/2004, Harald Tveit Alvestrand wrote: >>[dragging the author into an IETF list discussion] >> >>ouch.... >> >>the language on leap seconds was added because I asked about it at IESG >>evaluation time. >> >>I think Russ' intention for this was that you should be able to copy the >>Unix time() into it without any further thinking (except wondering >>whether the clock is accurate) - "ignoring leap seconds" rather obviously >>doesn't say the same thing to everyone.... >> >>Suggestions for rewording? Russ? >> >> Harald >> >>--On mandag, november 15, 2004 16:29:30 +0100 Simon Leinen >><simon@limmat.switch.ch> wrote: >> >>>Graham Klyne writes: >>>>>The integer value is the number of seconds after midnight UTC, >>>>>January 1, 1970. >>>>> >>>>>NEW: >>>>> >>>>>The integer value is the number of seconds, ignoring leap seconds, >>>>>after midnight UTC, January 1, 1970. >>> >>>>This slipped under my radar until this announcement. >>> >>>>Has there been detailed discussion of leap second issues? What >>>>exactly does the revised text "ignoring leap seconds" actually mean >>>>(I think I can guess, but I also think there's some room for >>>>misinterpretation here)? >>> >>>Yes. Maybe "excluding leap seconds" would have been clearer. >>>-- >>>Simon. >>> >>> >>>_______________________________________________ >>>Ietf mailing list >>>Ietf@ietf.org >>>https://www1.ietf.org/mailman/listinfo/ietf >> >> >------------ >Graham Klyne >For email: >http://www.ninebynine.org/#Contact
Received on Wednesday, 17 November 2004 10:14:26 UTC