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

[Carsten Bormann <[e-mail]>]

On Feb 14, 2019, at 13:49, Richter, Jörg <[e-mail]> wrote:
> 
> 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.

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.

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

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

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

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
> cannot be used as is.  (Which is as it happens our internal resolution of
> points in time and time of day)


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

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

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

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

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.

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

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