Subject: [core] Date option in draft-shelby-core-coap-01

From: Peter Bigot <[email-masked]>
Date: Thu, 13 May 2010 09:35:25 -0500

Section 3.3.6 introduces a Date option that can be used to timestamp a
measurement.  The description specifies that leap seconds are excluded.
It's not crystal clear to me what "excluded" means in this situation.  I
don't see any discussion in the list archive.

Pretending leap seconds don't exist (one sense of exclude) makes sense as it
trivializes the translation between POSIX- time representations (seconds
since 1970-01-01T00:00:00Z) and UTC-aligned wall clock times that people
normally deal with: this becomes simple division and modulus operations with
a little hassle imposed by leap years.  On the other hand, the
representation can express times that do not exist (23:59:59 when a negative
leap second takes effect), and can be ambiguous (23:59:60 or a repeated
23:59:59 when a positive leap second takes effect).  More importantly,
simple subtraction of two event times does not necessarily result in the
duration of the event.

For an in-development system to which CoAP could apply, my recommendation
was to use times expressed as atomic seconds since the POSIX epoch (thereby
excluding leap second adjustments from the value).  This does mean that
translation to civil time requires knowledge of the number of leap seconds
in effect at that time (currently UTC is 24 seconds behind TAI relative to
the POSIX epoch).  In return, devices that maintain an internal clock used
to timestamp events do not need to be updated to take into account leap
second adjustments, which can take a fair amount of code and support
infrastructure to handle a very rare event.  It also trivializes calculation
of event durations, even when the duration spans application of a leap
second.

My feeling is that any software component that needs to translate between
between device time and civil time can be expected to account for leap
seconds, while those that are operating in a constrained environment would
best be isolated from their effects.  Note that GPS time is similarly
measured in atomic seconds since an epoch (1980-01-06T00:00:00Z).

So, do Date values in the proposed COAP match what you get from running
"date +%s" on a Linux system synchronized to UTC, or are they that value
plus 24?  I read the draft as specifying the latter, which is my preference,
but anticipate great confusion from people who haven't had to deal with leap
seconds before.

Recommend changing "number of seconds, excluding leap seconds, after" to
"number of (atomic) seconds since".

Peter

---

From: Cullen Jennings <[email-masked]>
Date: Wed, 26 May 2010 21:05:36 -0600

Peter, 

These are all excellent points and I think I (not Zach) am partial to blame for the current text... I just pointed him towards some cut and pasted text from some other RFC - I figured we needed something in the draft as a starting point to get this conversation going. Dealing with time is always complicated and even more so in this constrained environment. If we start by looking at our constraints, I suspect we come to the conclusions you suggested below. 

My guess is that if we asked everyone, most people would say that we could not require a COAP node to do any of the following. Some nodes might do these but it would not be required

1) run NTP 
2) have a table of when leap seconds were going to happened and way to keep that table up to date 
3) have a time source was more accurate than a simple non temperature compensated crystal 
4) have any clue about timezones 

I really have no idea how some of these devices are even going to set their time when they first get turned on other than perhaps looking at the time of some other node. 

All this leads me to wonder if we could get away with only having relative times in CoAP. 

On May 13, 2010, at 8:35 AM, Peter Bigot wrote:

> Section 3.3.6 introduces a Date option that can be used to timestamp a measurement.  The description specifies that leap seconds are excluded.  It's not crystal clear to me what "excluded" means in this situation.  I don't see any discussion in the list archive.
> 
> Pretending leap seconds don't exist (one sense of exclude) makes sense as it trivializes the translation between POSIX- time representations (seconds since 1970-01-01T00:00:00Z) and UTC-aligned wall clock times that people normally deal with: this becomes simple division and modulus operations with a little hassle imposed by leap years.  On the other hand, the representation can express times that do not exist (23:59:59 when a negative leap second takes effect), and can be ambiguous (23:59:60 or a repeated 23:59:59 when a positive leap second takes effect).  More importantly, simple subtraction of two event times does not necessarily result in the duration of the event.
> 
> For an in-development system to which CoAP could apply, my recommendation was to use times expressed as atomic seconds since the POSIX epoch (thereby excluding leap second adjustments from the value).  This does mean that translation to civil time requires knowledge of the number of leap seconds in effect at that time (currently UTC is 24 seconds behind TAI relative to the POSIX epoch).  In return, devices that maintain an internal clock used to timestamp events do not need to be updated to take into account leap second adjustments, which can take a fair amount of code and support infrastructure to handle a very rare event.  It also trivializes calculation of event durations, even when the duration spans application of a leap second.
> 
> My feeling is that any software component that needs to translate between between device time and civil time can be expected to account for leap seconds, while those that are operating in a constrained environment would best be isolated from their effects.  Note that GPS time is similarly measured in atomic seconds since an epoch (1980-01-06T00:00:00Z).
> 
> So, do Date values in the proposed COAP match what you get from running "date +%s" on a Linux system synchronized to UTC, or are they that value plus 24?  I read the draft as specifying the latter, which is my preference, but anticipate great confusion from people who haven't had to deal with leap seconds before.
> 
> Recommend changing "number of seconds, excluding leap seconds, after" to "number of (atomic) seconds since".

I suspect that using a EPOCH of 2010 instead of 1970 would reduce the bits we need and also, more importantly, encourage people not to confuse these times with "date +%s"  times. 

> 
> Peter
> _______________________________________________
> core mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/core

Cullen Jennings
For corporate legal information go to:
http://www.cisco.com/web/about/doing_business/legal/cri/index.html

---

From: Peter Bigot <[email-masked]>
Date: Thu, 27 May 2010 09:14:08 -0500

I doubt relative times would work, since every device would have its own
zero, making coordination difficult.

I agree with your assessment of what can be asked of COAP nodes with respect
to time.  Any requirement that the nodes operate with civil time (or UTC)
would require something like 1, 2, or 4.
If the phrasing I suggested were adopted, it would be the responsibility of
whatever bridges between COAP and less constrained environments to make the
necessary adjustments.

3 is more of an issue, as it implies the times on COAP nodes may drift so
much leap days (let alone seconds) would be in the noise.  But we have to
draw the line somewhere.

I recommend retaining the POSIX epoch of 1970.  Moving to 2010 would not
help much, as there are 86400 seconds in a day and 31536000 in a year,
meaning neither 16 nor 24 bits are adequate for measuring reasonable time
periods.  Once we're at 32 bits, we might as well keep a standard epoch
rather than create a new one.  (We could move to GPS time, which has a
different epoch and a different UTC offset, but I suspect most developers of
COAP applications will be more familiar with POSIX.)

Peter

On Wed, May 26, 2010 at 10:05 PM, Cullen Jennings <[email-masked]> wrote:

>
> Peter,
>
> These are all excellent points and I think I (not Zach) am partial to blame
> for the current text... I just pointed him towards some cut and pasted text
> from some other RFC - I figured we needed something in the draft as a
> starting point to get this conversation going. Dealing with time is always
> complicated and even more so in this constrained environment. If we start by
> looking at our constraints, I suspect we come to the conclusions you
> suggested below.
>
> My guess is that if we asked everyone, most people would say that we could
> not require a COAP node to do any of the following. Some nodes might do
> these but it would not be required
>
> 1) run NTP
> I really have no idea how some of these devices are even going to set their
> time when they first get turned on other than perhaps looking at the time of
> some other node.
>
> > Pretending leap seconds don't exist (one sense of exclude) makes sense as
> it trivializes the translation between POSIX- time representations (seconds
> I suspect that using a EPOCH of 2010 instead of 1970 would reduce the bits
> we need and also, more importantly, encourage people not to confuse these
> times with "date +%s"  times.
>
> >
> > Peter

---

From: "Angelo P. Castellani" <[email-masked]>
Date: Fri, 28 May 2010 15:19:49 +0200

Cullen,

I agree with you about relative times in CoAP.

Under the assumption that message delay is smaller of the required
accuracy, using a flag we can distinguish between absolute time and
relative time.

In my opinion POSIX format for absolute time is good (we can also
represent events in the past, useful?), relative time can be
represented with a signed integer of a similar size.

Best,
Angelo