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

[Richter, Jörg <[e-mail]>]

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

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

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

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