Subject: [Cbor] Proposal for Date, Time and Time Zones

From: Richter, Jörg <[email-masked]>
Date: Thu, 14 Feb 2019 08:31:06 +0000

Here is a proposal to assign tags to date, time of day and time zone designator:
https://j-richter.github.io/CBOR/date.html

For the tags I have chosen values between 24 and 255. For date and time I could imagine
to use smaller tags, because the encoded payload is very short.

Do you have better suggestions for the tags?

---

From: Carsten Bormann <[email-masked]>
Date: Thu, 14 Feb 2019 11:13:52 +0100

> https://j-richter.github.io/CBOR/date.html

I think it is interesting to compare this approach with that of tag 1001.

Tag 1001 tries to combine necessary information (to identify a point in time) into a single data structure.

Your proposal differs in two ways:
(1) the date/time-of-day/timezone information is unbundled into separate tags.
(2) the relation to time zones is implicit (contextual).

Specifically:
— the “date” seems to stand for the entire 24-hour interval of the given day in some timezone taken from the context
— the “time” (really time of day) stands for any point in time that corresponds to that time of day (again in a time zone taken from the context)
— the “time zone” stands alone, i.e., is useful without such contextual information.

All of these would make good fields in a 1001-style map (which would provide the context), except that “date” really is an interval (which ) and “time” (time of day) really is a recurring event.

> Do you have better suggestions for the tags?

I think the tags proposed are fine.  I’m interested in where the two different approaches would be used (and how to get the interval/periodic event function into tag 1001-1003).

Grüße, Carsten

---

From: Richter, Jörg <[email-masked]>
Date: Thu, 14 Feb 2019 12:49:08 +0000

The main motivation for date and time of day is to just represent 
the semantic information.  Without a need to assign one or more points in time.

No one cares whether his birthday was 23, 24 or 25 hours long.  
Opening hours of stock exchanges are also just represented as a pair of clock times.
Of course, deriving concrete points in time requires always context information 
like the time zone of the stock exchange. But this information should not be 
part of the clock time.

As I see it, tag 1001 is useful for points in time.  I find it particularly 
good that decimal fractions can also be used. I am unsure about the negative
keys. Don't they do the same as a decimal fraction? And unusual scaling like 10^-7
cannot be used as is.  (Which is as it happens our internal resolution of
points in time and time of day)

I can't quite imagine how the concepts could be unified. Do you have an 
idea in mind?  All 4 types (timestamp, date, time of day, time zone) are used 
separately in our code.  To me it makes sense to represent them distinctly in CBOR.

About leap seconds: Now that I think about it, is tag 0 defined with leap seconds 
or without?  This might pose a problem (for us).  Anybody know what other 
encoders/decoders do?

> I’m interested in where the two
> different approaches would be used (and how to get the interval/periodic
> event function into tag 1001-1003).

I think I understand 1001.  And I think the two are different semantic concepts.
But I cannot find anything about tags 1002 and 1003.  The draft for 1001
does not contain much information about it.  Is there another document somewhere?

- Jörg

---

From: Carsten Bormann <[email-masked]>
Date: Thu, 14 Feb 2019 14:52:16 +0100

> the semantic information.  Without a need to assign one or more points in time.

Right, that’s why I think they stand on their own.  But I still would like to understand the whole picture.
It would be nice if we could come up with a coherent narrative on when to use which of these tags.

> like the time zone of the stock exchange. But this information should not be 

There are applications that would prefer it to be.
However, other applications may not need it, and the proposed tags are fine for those.

> keys. Don’t they do the same as a decimal fraction?

Yes, but they save having to combine full seconds and decimal fractions into a single number, which would be needed for bigdecimals (CBOR Tag 4).  Many UNIX times, as well as the Haskell time which actually motivated writing the draft, come in seconds/decimal fractions.

> And unusual scaling like 10^-7

If you don’t have split seconds/fractions, you can use Key 4.
If you do, and want to preserve the split, we could introduce Key -7.
Is that a common representation?
I’m familiar with using 10 MHz clocks for frequency references, but wasn’t aware of its use for time reference.
You could also use Key -9, at the cost of one multiplication by 100 (encoding) or division by 100 (decoding).

> separately in our code.  To me it makes sense to represent them distinctly in CBOR.

It does.  We might want to use the contents of the timezone tag as a Key for Tag 1001 right away.

> or without?  This might pose a problem (for us).  Anybody know what other 

Tag 0 and 1 use civil time, i.e., time based on UTC.  For Tag 1, this uses the weird Posix format where a leap second and its preceding second cannot be distinguished.  (This is not a problem for Tag 0, if used properly; many implementations of the RFC 3339 underlying Tag 0 will however map to Posix time internally and so will have idiosyncrasies around leap seconds.)

(I can’t answer the actual question: I don’t know whether you consider “with/without leap seconds” to be equivalent to UTC/TAI or the other way around; the terminology here is not very sharp.)

For Tag 1001, we intend to have a map key that indicates the time scale, which would then clearly include TAI as one option.  This is not in the draft yet because we want to discuss this with an actual user of atomic time.
We also have some quite positive feedback for including leap-second smeared time scales (but which ones?) as further alternatives.

> does not contain much information about it.  Is there another document somewhere?

The earlier versions of the draft contained a little more, which we have cut down for -02.
Again, we would like to nail these down based on input from actual users of the concepts of duration and interval (including their thinking about semantic dates and concepts such as leap seconds and time zone changes).

As a way forward, I wouldn’t mind including the new tags in the time-tag Internet-Draft, so we have a place where the consistent narrative mentioned above can be put.

Grüße, Carsten

---

From: Richter, Jörg <[email-masked]>
Date: Thu, 14 Feb 2019 14:55:34 +0000

> Yes, but they save having to combine full seconds and decimal fractions
> into a single number, which would be needed for bigdecimals (CBOR Tag 4).
> Many UNIX times, as well as the Haskell time which actually motivated
> writing the draft, come in seconds/decimal fractions.

Ahh okay.  Seems like I have misunderstood this usage.  We always have
our seconds and fractions combined.  

> Is that a common representation?

I think not.

> You could also use Key -9, at the cost of one multiplication by 100
> (encoding) or division by 100 (decoding).

We considered this, but then 64 bits are not enough for the time span we
want to support which is around 10000 years.  And multiplying by 100
will result in a bignum instead of an int64.

> Tag 0 and 1 use civil time, i.e., time based on UTC.  For Tag 1, this uses
> the weird Posix format where a leap second and its preceding second cannot
> be distinguished. 

Okay.  Then this is what we use.  In my opinion this is more practical useful.

> For Tag 1001, we intend to have a map key that indicates the time scale,
> which would then clearly include TAI as one option.  This is not in the
> draft yet because we want to discuss this with an actual user of atomic
> time.
> We also have some quite positive feedback for including leap-second
> smeared time scales (but which ones?) as further alternatives.

I think time scales that avoid leap seconds will always be preferred. 
Unfortunately I can't be of much help because I don't know much about it. 
By "avoiding leap seconds" I mean that the UTC-day can be easily computed 
by dividing by 86400.

> Again, we would like to nail these down based on input from actual users
> of the concepts of duration and interval (including their thinking about
> semantic dates and concepts such as leap seconds and time zone changes).

I don't know if it's any help, but there are other types we use:
* time duration in fractional seconds
* UTC offset in seconds (like +01:00)
* period of time (like "3 months" or "7 weeks"). 
  It consists of two parts. A whole number and the unit.
* and any element of a date like "year", "hour of the day" etc.

But for now we don't need tags for those.
And we "ignore" leap seconds, like all other systems our product connects to.

Some other points:
I think I will extent the proposal for time of day to include decimal fraction.
Is it possible to extent Tag 1 to also accept decimal fraction?

- Jörg