Re: [Cbor] [EXTERNAL] Re: draft-ietf-cbor-date-tag-02 - handling of time zone offsets

[Henk Birkholz <[e-mail]>]

On 16.07.20 18:10, Carsten Bormann wrote:
> On 2020-07-16, at 17:58, Mike Jones <Michael.Jones=[e-mail]> wrote:
>>
>> Mike> 1.3 was added in response to comments by Jim Schaad - also with input from Carsten Bormann and is about comparing dates and times. As to why tags weren't added for time values - there was a present use case for date values and there wasn't for time values.  Another spec can always define and add such tags to the registry in the future.
> 
> Actually, Joerg’s initial proposal included numeric date, numeric time-of-day, and timezone (using timezone database IDs).
> 
> Numeric date was extracted from that for this draft, but we certainly want to come back to the rest of the proposal.
> 
> 			.oOo.
> 
> As a general comment, we really have to work on some terminology here.

+1 (to no big surprise, I'd assume)
But where would that text go? (or better, to which Appendix)

Falso see:

https://www.ietf.org/timezones/data/theory.html

> 
> Date (the new tags): a concept related to calendars
> Date-time (Tags 0, 1, 1001): anchored on a time scale (which usually relates to calendars via time zones)
> Time-of-day (todo, also usually needs time zones)

We were already talking about the first two and there were already some 
questions about the "why" (...someone would want to make a strict 
differentiation here, how it would look like) and "what" exactly.

Time-of-day is adding a bit complexity to the confusion, I am afraid: It 
always comes with a scope, I think. If the scope is around a single 
clock instead multiples, the meaning of it changes. Effectively, 
time-of-day is a relative timescale with 86400 seconds (for a solar day, 
not sidereal day), its own epoch, and that does not require a time zone, 
if the scope is limited to a single clock.

> These things are related in complicated ways.  They become more complicated when they don’t just document a past event, but actually are trying to schedule into the future; recurrent schedules being even more complicated.

Multiple timescales use the same epoch, but arrive at different time 
values at a given point in time 
(https://www.ietf.org/timezones/data/leap-seconds.list). Some of the 
complexity could be addressed with some good expositional text. Maybe in 
time-tag?

> 
> (“Time” is ambiguous, because some people think it is time-of-day, others think it is a date-time or time on a timescale that uses another epoch, such as Posix-time.  So let’s use more specific terms whenever possible.)
> 
> Grüße, Carsten
> 
> _______________________________________________
> CBOR mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/cbor
>