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

["Angelo P. Castellani" <[e-mail]>]

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

On Thu, May 27, 2010 at 05:05, Cullen Jennings <[e-mail]> 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
> 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
>> [e-mail]
>> 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
>
>
>
> _______________________________________________
> core mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/core
>