W3C home > Mailing lists > Public > www-archive@w3.org > November 2004

Re: Document Action: 'BinaryTime: An alternate format for representing date and time in ASN.1' to Experimental RFC

From: Graham Klyne <GK-lists@ninebynine.org>
Date: Wed, 17 Nov 2004 09:34:35 +0000
Message-Id: <>
To: Russ Housley <housley@vigilsec.com>, Harald Tveit Alvestrand <harald@alvestrand.no>, Simon Leinen <simon@limmat.switch.ch>, Pete Resnick <presnick@qualcomm.com>


[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.


[1] Approximate locus of Haskell library discussion:

[2] Pretty much my own current view in that debate...
(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?
>At 11:02 PM 11/15/2004, Harald Tveit Alvestrand wrote:
>>[dragging the author into an IETF list discussion]
>>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.
>>>>>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.
>>>Ietf mailing list
>Graham Klyne
>For email:
Received on Wednesday, 17 November 2004 10:14:26 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 22:32:38 UTC