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

From: Graham Klyne <[email-masked]>
Date: Mon, 15 Nov 2004 12:29:00 +0000

At 13:13 12/11/04 -0500, you wrote:
>The IESG has approved the following document:
>
>- 'BinaryTime: An alternate format for representing date and time in ASN.1 '
>    <draft-housley-binarytime-02.txt> as an Experimental RFC
>
>This document has been reviewed in the IETF but is not the product of an
>IETF Working Group.
>
>The IESG contact person is Steve Bellovin.
>
>Technical Summary
>   This protocol provides a means to represent time in ASN.1 as an integral
>number of seconds since the epoch (00:00:00 UTC, January 1, 1970).  This 
>avoids
>the well-known problems with comparison of timestamps that are given with
>respect to some particular timezone.
>
>Protocol Quality
>
>  Steve Bellovin has reviewed this document for the IESG.
>
>RFC Editor Note:
>
>Section 2, old text:
>       BinaryTime ::= INTEGER
>
>New text:
>        BinaryTime ::= INTEGER (0..MAX)
>OLD:
>
>     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)?  Has 
any consideration been given to conversion between the integer timestamp 
and more conventional representations involving dates and times;  if so, is 
that documented?

My view is that leap seconds are a small detail which have great potential 
for causing confusion.  I've been involved in some discussion of a 
date-time library for a programming language (Haskell) [1], which 
discussion is currently stalled because of unresolved leap second issues.

A particular concern of mine is that if a simple count of elapsed seconds 
is used, then there is no way to define an algorithm for accurately 
determining the correspondence between this binary timestamp and (say) ISO 
8601 date-time representations.  Leap second occurrences are not known very 
far in advance.

My own preference [2] for a binary time representation is to use a pair of 
numbers:  a day count and a second (or sub-second) count.  I feel this 
adequately handles the vast majority of use-cases for timestamps in 
applications that do not care or know about leap-seconds (i.e. where the 
inaccuracies of not considering leap-seconds are not considered 
significant), or when the intervals concerned are generally much less than 
a day and hence are measured it terms of time only, but still allows 
specialized applications that do know about such things to make the 
appropriate adjustments when working with timestamps and time intervals.

I submit these as considerations for when the experimental status of this 
specification is reviewed, and request that the resolutions be documented 
if the specification moves from experimental to standards-track status.

#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")

------------
Graham Klyne
For email:
http://www.ninebynine.org/#Contact

_______________________________________________
Ietf mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ietf

---

From: Simon Leinen <[email-masked]>
Date: Mon, 15 Nov 2004 16:29:30 +0100

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

---

From: Harald Tveit Alvestrand <[email-masked]>
Date: Tue, 16 Nov 2004 05:02:00 +0100

[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

---

From: Alan Barrett <[email-masked]>
Date: Tue, 16 Nov 2004 11:08:53 +0200

On Mon, 15 Nov 2004, Graham Klyne wrote:
> guess, but I also think there's some room for misinterpretation here)?

I assume it means "assuming exactly 86400 seconds per day".

--apb (Alan Barrett)

---

From: "Randy Presuhn" <[email-masked]>
Date: Tue, 16 Nov 2004 11:22:44 -0800

Hi -

> From: "Alan Barrett" <[email-masked]>
> To: <[email-masked]>
> Sent: Tuesday, November 16, 2004 1:08 AM
> Subject: Re: Document Action: 'BinaryTime: An alternate format forrepresenting date and time in ASN.1' to Experimental RFC
>

> I assume it means "assuming exactly 86400 seconds per day".
...

I had understood it to mean that the values coming from the seconds
clock would have no gaps or duplicates due to leap seconds.  This is very
useful if the system needs to calculate accurate intervals, especially if it
won't be receiving software updates to tell it when leap seconds have
occurred.  An assumption of "exactly  86400 seconds per day" means
that the seconds clock would have to be advanced (or possibly set back)
at the time the leap second is to be inserted so that the fiction of an
86400-second day could be maintained, and would thus require that
the system be informed when leap seconds are to be inserted.  Otherwise,
dates and times derived form the clock would drift.

This is an old debate.

Randy

---

From: Pete Resnick <[email-masked]>
Date: Tue, 16 Nov 2004 18:07:43 -0600

On 11/16/04 at 5:02 AM +0100, Harald Tveit Alvestrand wrote:

>>>>The integer value is the number of seconds, ignoring leap 
>>>>seconds, after midnight UTC, January 1, 1970.
>
>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....
>

I think you want to go back to the old wording. If you need a 
reference to insert, see RFC 1305, Appendix E, sections 7 & 8.

pr
--
Pete Resnick <http://www.qualcomm.com/~presnick/>
QUALCOMM Incorporated - Direct phone: (858)651-4478, Fax: (858)651-1102