Subject: [Cbor] CBOR Tags for Time, Duration, Period

From: Carsten Bormann <[email-masked]>
Date: Mon, 13 Mar 2017 20:31:00 +0100

We have written a straw man draft for a few CBOR tags that would allow more information in a time than is provided in tags 0 and 1, and would also allow representing durations and time periods.

https://tools.ietf.org/html/draft-bormann-cbor-time-tag-00

Note that the CBOR WG is not currently chartered to work on documents like these, but that does not have to stop any WG member from sending comments, even on this list :-)

Grüße, Carsten

---

From: <[email-masked]>
Date: Tue, 14 Mar 2017 21:47:07 +0000

This looks like a good start.

I would recommend discarding UI and presentation elements such as timezone, location, and presentation calendar.  These "interpretive" elements would perhaps be better served with additional meta data sent along with a timestamp in an application specific manner.  This would keep the proposal laser focused on how to represent a higher precision time and meta data associated with the time value such as precision and accuracy.

Why stop at -12 for higher precision?   A 64 bit value can represent 10^-18 fractional seconds.

The traditional meaning of period in my mind is a duration specified as fields (years, days, minute etc).  I would suggest just supporting Duration for this proposal.

Could the text for Duration be as simple as Time

        A Duration represents the difference in time between two Time values.  It is encoded in the same manner as Time with the resulting value representing an offset from an arbitrary start point rather than relative to a standards specified epoch.  

Alternatively, could a duration simply be a Time with Key-1 set to "1" to indicate Duration (no time scale). 

--
Glenn

-----Original Message-----
From: CBOR [mailto:[email-masked]] On Behalf Of Carsten Bormann
Sent: Monday, March 13, 2017 12:31 PM
To: [email-masked]
Subject: [Cbor] CBOR Tags for Time, Duration, Period

Grüße, Carsten

_______________________________________________
CBOR mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/cbor

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 15 Mar 2017 11:30:49 +1300

On 15/03/2017 10:47, [email-masked] wrote:
> I would recommend discarding UI and presentation elements such as timezone, location, and presentation calendar.  These "interpretive" elements would perhaps be better served with additional meta data sent along with a timestamp in an application specific manner.  

I can't quite agree with that for the timezone. A time without a timezone is not
meaningful, not even locally. I don't mean the *name* of the timezone, but the offset
from UTC (or whatever other time scale is indicated). Either that or require that the
time is always sent as UTC(or TAI or whatever). If that's intended, the text probably
needs to say it explicitly.

   Brian

> This would keep the proposal laser focused on how to represent a higher precision time and meta data associated with the time value such as precision and accuracy.
>

---

From: <[email-masked]>
Date: Wed, 15 Mar 2017 00:36:53 +0000

I think we may be in agreement as this proposal specifies time encoded as UTC or TAI via Key -1 which defaults to UTC (as does CBOR tag 1). 

For our applications we've removed all references to time zone when shuttling data around.   If I timestamp something in California and store it in a data center in the UK and view it from India the timezone has no meaning so we convert to UTC at our first opportunity.  By transporting and storing in UTC (or TAI for purists worried about physical events where missing a leap second matters) the time is a known instant in time regardless of what timezone it was created.

This allows use of timezone to be a local application presentation issue (I'm in Greenland and want to see a timestamp - show it in my local timezone).  If I want to see the local time where a timestamp was created I would be best served by including GPS coordinates (and perhaps timezone) as independent but coupled meta data.

--
Glenn

-----Original Message-----
From: Brian E Carpenter [mailto:[email-masked]] 
Sent: Tuesday, March 14, 2017 3:31 PM
To: ENGEL,GLENN (K-Labs,ex1) <[email-masked]>; [email-masked]; [email-masked]
Subject: Re: [Cbor] CBOR Tags for Time, Duration, Period

> I would recommend discarding UI and presentation elements such as timezone, location, and presentation calendar.  These "interpretive" elements would perhaps be better served with additional meta d…

I can't quite agree with that for the timezone. A time without a timezone is not meaningful, not even locally. I don't mean the *name* of the timezone, but the offset from UTC (or whatever other time scale is indicated). Either that or require that the time is always sent as UTC(or TAI or whatever). If that's intended, the text probably needs to say it explicitly.

   Brian

> Note that the CBOR WG is not currently chartered to work on documents 
> like these, but that does not have to stop any WG member from sending 
> comments, even on this list :-)
> 
> Grüße, Carsten
>

---

From: Carsten Bormann <[email-masked]>
Date: Wed, 15 Mar 2017 13:01:41 +0100

> I think we may be in agreement as this proposal specifies time encoded as UTC or TAI via Key -1 which defaults to UTC (as does CBOR tag 1). 

Right, as written, the “hard time” is always in a globally referenced time scale, and this is probably also a good criteria to use for future registrations for key -1.

> For our applications we've removed all references to time zone when shuttling data around.   […]
> This allows use of timezone to be a local application presentation issue (I'm in Greenland and want to see a timestamp - show it in my local timezone).  

That depends.  The security event “Someone opened a Window at 03:00 UTC” has quite different implication whether that happened in the German timezone or in the Korean one.
This is an example of “context” or “intent” information that may be delivered with a timestamp.

> If I want to see the local time where a timestamp was created I would be best served by including GPS coordinates (and perhaps timezone) as independent but coupled meta data.

That leaves the task of looking up timezones to the recipient.
That is in many, but not all cases quite OK.

The design question really is whether time-related information should be attachable to the timestamp (and, yes, that might even include GPS coordinates) or should always be part of the surrounding context.  The current draft takes the stance that there is common “context” information that could be stored with the timestamp.   For timezone, there is precedent both in ISO 8601 (which, however, indicates the translated local time with the timezone, which we feel is less useful) and POSIX (e.g., tm_isdst).

Also, for future times, it may be useful to know what the originator of the time value is assuming are going to be the tz/dst values in that future.  (This doesn’t solve the problem of “We’ll meet in Chicago at 10 AM”, though; maybe ISO8601 is what you want to use for that.)

We’ve yet to align the draft with other important sources of wisdom such as http://www.boost.org/doc/libs/1_63_0/doc/html/date_time/posix_time.html, so this is all definitely subject to discussion. 

Grüße, Carsten

---

From: Carsten Bormann <[email-masked]>
Date: Wed, 15 Mar 2017 13:13:26 +0100

> On 14 Mar 2017, at 22:47, [email-masked] wrote:
> 

Does Keysight have an instrument that could take advantage of that (light advances 300 nm in 1 fs)?

(As the table indicates, the current set was a reaction to formats that are in good use, but I’m sure interested in planning for advances in this space.)

> The traditional meaning of period in my mind is a duration specified as fields (years, days, minute etc).  I would suggest just supporting Duration for this proposal.

Period is anchored in time, duration is not.
We could simply leave to representation of periods as pairs of time points (or of duration and time point) to the application.  But then there is RFC 3339...

> Alternatively, could a duration simply be a Time with Key-1 set to "1" to indicate Duration (no time scale). 

The representation is not going to be very different (obviously, an epoch-based time point is a duration from the epoch).  But the semantics is quite different, so it may make sense to have a separate tag, with essentially the same structure.  (Also, there is RFC 3339 again.)

(Periods are a bit different from durations also in that knowledge of the time points means that you know whether the underlying time scale is monotonic during the period.  E.g., the period from 23:59:59Z on Dec 31. 2016 to 00:00:00Z on Jan 1, 2017 was rather different from the similar period a year earlier.)

Grüße, Carsten

---

From: Christoph Engelbert <[email-masked]>
Date: Wed, 15 Mar 2017 13:13:36 +0100

Hey guys,

I think Carsten brought up a very valid point. There are timestamps that need additional information to be useful. Coming back to the window example, a security alert might only be kicked off if the 3am was in the window’s local timezone, it doesn’t matter what timezone the viewer of the information is in.

The question though is, does that timezone information need to be stored in the time value itself? Yes and no, it sometimes might be useful, maybe necessary, but sometimes not. As far as it seems to me, I could present both versions with the current proposal. Do I miss something?

Chris

> On 15. Mar 2017, at 13:01, Carsten Bormann <[email-masked]> wrote:
>

---

From: Henk Birkholz <[email-masked]>
Date: Wed, 15 Mar 2017 13:25:33 +0100

Hello all,

I'll just limit my comment to "time zone designation" vs "effective time 
zone offset". There are - as expected - different opinions about this.

On one hand, the tz label leaves it up the consumer to find out which 
offset that actually was at that point in past time (timestamp). "Right 
now" (aka the most recent past time) is a perfect example: the us 
switched to DST already - the eu did not. In consequence I was an hour 
late yesterday and missed a call. "time zone designation" did not help 
me, an "effective time zone offset would have" (assuming no 
complementary sources of context data).

Then again, the geographic limits of tz can be... "in dispute". Let's 
say.... they have to be assumed to be in constant flux due to politics. 
Also, highlighting just the offset does not imply if there will be a 
change to DST in the corresponding tz (e.g. not every us state switches 
into DST, if my memory serves me well), and it therefore does not enable 
a deterministic inference of the corresponding tz.

I.e. as with most time/duration/calender related context attribute, I 
would simply allow to include the one desired (XOR, OR and AND) in a 
timestamp as "optional context attributes". Because, what would be the 
reason not to (and there might be one. I just did not see a compelling 
one, yet - which might change at any... future time)?

Cheers,

Henk

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 16 Mar 2017 04:07:40 +1300

> Right, as written, the “hard time” is always in a globally referenced time scale, and this is probably also a good criteria to use for future registrations for key -1.

I now understand that to be your intention but I did *not* understand that on my
first reading of the text. Can you make it explicit somehwere, perhaps in the
description of key -1:

Note that the time indicated by Key 1, 2, 4 or 5 is given in the indicated or
implicit time scale with no offset.

Regards
   Brian

> .

---

From: <[email-masked]>
Date: Wed, 15 Mar 2017 17:37:53 +0000

> (As the table indicates, the current set was a reaction to formats that are in good use, but I’m sure interested in planning for advances in this space.)

I think it's a matter of planning for the future.   There are network cards that timestamp in 250 picosecond resolution.  Keysight sells optical modulation analyzers that measure 1Tb/s signals so 10^-15 is something that is reasonable to see in the future.  

Regarding timezone, the current document for Key -7 says it is what would be the "best fit for displaying to humans".  This is very application dependent.  I may want it in my own local time so I can get a quick measure of how long ago it happened.  As mentioned for the window sensor event, the operator might want to know the local time where the event occurred to determine the response action.  If I'm distributing a timestamp to align radio telescopes in different regions to make a coherent measurement at a specific time, I don’t want a timezone at all because each recipient may want to display it for humans in their own local time.   I think the meaning and use of timezone is so application dependent that it should be separated from the specification of the timestamp itself.  

--
Glenn

---

From: Sean Leonard <[email-masked]>
Date: Wed, 29 Mar 2017 13:51:32 -0500

Hello, there seems to be a very active discussion about time on the ART mailing list. I think it is driven by NTP needs, but folks who want time in CBOR should take a look at that. It appears that draft-bormann-cbor-time-tag-00 tracks the issues being raised in that thread (Subject: Predictable Internet Time).

Looking at that discussion, it seems to me that time is “complicated”, and probably too complicated for most development needs. I look at the ASN.1 spec [X.680] which devotes several sections to Time issues with tons of different time formats. I believe that is the wrong approach, because implementations of the base standard need to handle all of those esoteric corner cases.

I would rather see effort in CBOR be minimized for base implementations, and elaborated upon only in situations that require it. I.e., if a protocol based on CBOR needs TAI time, then there should be a specific TAI time format with its own CBOR tag or whatever, defined when someone actually needs it, rather than a general extensive mechanism with a bajillion different options.

Given all these time formats, is there some industry standard for representing different forms of time in one binary format, akin to what IEEE 754 does for floating-point numbers? I would rather see that form with one tag in CBOR, so that CBOR implementations don’t have to “Deal with It”--they can hand the data off to a different time-processing library.

Sean

> On Mar 13, 2017, at 2:31 PM, Carsten Bormann <[email-masked]> wrote:
>

---

From: Carsten Bormann <[email-masked]>
Date: Wed, 29 Mar 2017 14:44:51 -0500

> Hello, there seems to be a very active discussion about time on the ART mailing list. I think it is driven by NTP needs, but folks who want time in CBOR should take a look at that. It appears that…

Yes.

> Looking at that discussion, it seems to me that time is “complicated”,

Nobody knew that time could be so complicated!

> I would rather see effort in CBOR be minimized for base implementations,

Yes.
(We have tag 1 for those.)

> and elaborated upon only in situations that require it. I.e., if a protocol based on CBOR needs TAI time, then there should be a specific TAI time format with its own CBOR tag or whatever, defined when someone actually needs it, rather than a general extensive mechanism with a bajillion different options.

Options are bad, indeed.
Not quite so bad if you don’t have to use them, so.

(Having a bajillion tags for the different “simple cases” doesn’t sound much nicer.)

> Given all these time formats, is there some industry standard for representing different forms of time in one binary format, akin to what IEEE 754 does for floating-point numbers? I would rather se…

One would wish that.

Lacking that, we could define a tag that is useful for a collection of time-based IETF protocols that happen to use CBOR.  The current -00 is a first straw man showing a direction we could go.

Grüße, Carsten

---

From: Laurence Lundblade <[email-masked]>
Date: Wed, 29 Mar 2017 20:46:03 +0000

Sean said well, what I’ve been thinking since I first saw the proposal.

I’d suggest maybe even going this far - when expressing the current global time, canonical CBOR protocols should use UNIX Epoch time. This is the most clear, simple and compact way to express time. CBOR protocols are discouraged from using string-based time/date formats and from using local time + time zone.

LL

> On Mar 29, 2017, at 11:51 AM, Sean Leonard <[email-masked]> wrote:
>

---

From: <[email-masked]>
Date: Wed, 29 Mar 2017 21:48:27 +0000

Just to pile on the simplification approach...  The two standards I'm most familiar with (IEEE1588 Precision Time Protocol and LXI: Lan Extensions for Instrumentation) have gone with the simplified approach to define a timestamp as a strictly numeric quantity.   They make no mention of time zones or string representations.  Their wire format is a 96 bit representation of TAI with an optional UTC offset as meta data.  For those unfamiliar with TAI or UTC, TAI is a monotonically increasing counter from the UNIX Epoch counting elapsed seconds.  UTC accommodates leap seconds so the count may jump forward or backward depending on the whims of the earth's rotation speed.

In practice the TAI format is cumbersome since "many" applications are really interested in UTC and don't want to program in offsets that are determined randomly by some group of physicists.  Knowing the table of leap second adjustments one can convert between TAI and UTC easily enough but who wants to maintain a table in their code that can change a month after a code release?  Note though that conversion from UTC to TAI can be ambiguous at the leap second transition points.  Programmers will cheer if the oft proposed elimination of leap seconds comes about.

From my perspective, the main need to address is the issue that CBOR Tag 1 is ultimately only good for millisecond resolution.  My two cents is to simplify and only provide a mechanism to represent a high resolution timestamp (and interval) that can be tagged as either TAI or UTC.  Applications that really need TAI can communicate using TAI and others can use UTC.    UTC as an offset from the UNIX Epoch makes the most sense given the preponderance of this usage.

--
Glenn

-----Original Message-----
From: CBOR [mailto:[email-masked]] On Behalf Of Laurence Lundblade
Sent: Wednesday, March 29, 2017 1:46 PM
To: Sean Leonard <[email-masked]>
Cc: [email-masked]
Subject: Re: [Cbor] CBOR Tags for Time, Duration, Period

LL

---

From: Carsten Bormann <[email-masked]>
Date: Wed, 29 Mar 2017 16:52:01 -0500

On 29 Mar 2017, at 16:48, <[email-masked]> <[email-masked]> wrote:
> 
> Note though that conversion from UTC to TAI can be ambiguous at the leap second transition points.  

(That is a property of the POSIX time CBOR tag 1 uses, not of UTC per se.)

Grüße, Carsten

---

From: Laurence Lundblade <[email-masked]>
Date: Wed, 29 Mar 2017 22:45:42 +0000

> 
> On Mar 29, 2017, at 2:48 PM, [email-masked] wrote:
> 
> 
> From my perspective, the main need to address is the issue that CBOR Tag 1 is ultimately only good for millisecond resolution.  

It’s limited to millisecond resolution because of the limits of a double-precision float and that we’ve used up about half the bits for the non-fractional seconds here in 2017, right?  So we’d need a bigfloat?

> My two cents is to simplify and only provide a mechanism to represent a high resolution timestamp (and interval) that can be tagged as either TAI or UTC.  Applications that really need TAI can communicate using TAI and others can use UTC.    UTC as an offset from the UNIX Epoch makes the most sense given the preponderance of this usage.

Tag 1 is defined already as UTC.   Seems like we’d want to define a new tag value to for TAI.

Generally sounds good.

LL