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

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 1 Jul 2020 09:21:23 +0200

Hi,

I just saw your CBOR date type and it seems it does not include a
timezone offset. This means a date value does not represent a 24 hour
time interval but something larger. XML schema's date type allows the
optional inclusion of a timezone offset. The date definition in
draft-ietf-netmod-rfc6991-bis-03.txt (still under discussion) includes
a mandatory timezone offset (since it was already mandatory for
date-and-time). I do not know whether we should have a common approach
for this.

Note that your 'number of days since the epoch 1970-01-01 does not
really say 1970-01-01T00:00:00 and also leaves it open whether this is
calculated in UTC or not (on Unix-like systems, time is usually
counted in UTC).

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germany
Fax:   +49 421 200 3103         <https://www.jacobs-university.de/>

---

From: Carsten Bormann <[email-masked]>
Date: Wed, 1 Jul 2020 10:18:29 +0200

Hi Juergen,

thank you for that comment.

There are two different concepts of “date", and I think the current draft needs to be more explicit that it is about one and not the other.

> On 2020-07-01, at 09:21, Juergen Schoenwaelder <[email-masked]> wrote:
> 
> Hi,
> 
> time interval but something larger.

Well, it represents the abstract date, as opposed to a time period starting at 00:00 on that date and ending at 24:00, both in some time zone (which in practice may be 23, 24, 24.00028, or 25 hours).

Angela Merkel’s birthday was 1954-07-17.  You will find that on her passport.  The passport will be mute about the time zone in which she was born, as that is irrelevant to the identification principle.  (Other example: I was born at 00:05 UTC, but that doesn’t mean I have a different birthday in New York, where that specific instant would have been 20:05 the previous day, I think.)

> XML schema's date type allows the
> optional inclusion of a timezone offset.

Which is useful when you want to convert a date into that ~24-hour time period.

> The date definition in

I think there is a use case for these periods (see also draft-bormann-cbor-time-tag for a little more about periods, even though we haven’t started to flesh out that part of the spec).  It is not the one addressed by these tags.

> calculated in UTC or not (on Unix-like systems, time is usually

It doesn’t have to, as it talks about the date, not the anchoring in a time scale of the start and end of the period covering that date in a specific time zone.

Joerg’s original proposal has a separate tag for time zone, which (with the time zone data base and, depending on the time scale, information about leap seconds) may be used to do the conversion.  This is not included in the current draft, because the use case is for abstract dates, but it certainly will be addressed by some future tags.

Grüße, Carsten

---

From: Henk Birkholz <[email-masked]>
Date: Wed, 1 Jul 2020 10:44:29 +0200

Hi all,

in other words (and please correct me, if I am wrong):

Effectively, the date tag is about calendars instead of timescales. 
These are two separate concepts. In calendars you count days (e.g. day 
of year or days since epoch, based on the rotation of the earth around 
its axis), in timescales you count time intervals (e.g. time of day or 
seconds since epoch, typically based on the rotation of the earth around 
the sun). Both calendars and timescales can share the same epoch, though.

Viele Grüße,

Henk

On 01.07.20 10:18, Carsten Bormann wrote:
> _______________________________________________
> CBOR mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/cbor
>

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 1 Jul 2020 11:05:36 +0200

> Angela Merkel’s birthday was 1954-07-17.  You will find that on her passport.  The passport will be mute about the time zone in which she was born, as that is irrelevant to the identification princ…

I am not sure about Angela's passport but my passport in addition
states where I was born (which implies a certain time zone). I do not
know whether this example is useful or not, perhaps you just want to
say that in some use cases the time zone does not matter and this is
fine.

But on the other hand, two systems may tag an event with 1954-07-17
but in UTC they would be not the same dates or two systems can tag an
event with two different dates but they are actually the same date in
UTC. In distributed systems operating across many timezones, simple
comparisons of date values can be surprising.
 
> Which is useful when you want to convert a date into that ~24-hour time period.

Or you want to compare dates, see above.

> Joerg’s original proposal has a separate tag for time zone, which (with the time zone data base and, depending on the time scale, information about leap seconds) may be used to do the conversion.…

If the ambiguity caused by timezones is what this WG wants, fine. But
then I think the WG should add a warning that naive comparisons of
date values can be surprising.

Let me check POSIX.1 that is cited for the epoch. Section 4.16 says:

  If the year is >=1970 and the value is non-negative, the value is
  related to a Coordinated Universal Time name according to the
  C-language expression, where tm_sec, tm_min, tm_hour, tm_yday, and
  tm_year are all integer types:

  tm_sec + tm_min*60 + tm_hour*3600 + tm_yday*86400 +
    (tm_year-70)*31536000 + ((tm_year-69)/4)*86400 -
    ((tm_year-1)/100)*86400 + ((tm_year+299)/400)*86400

I read this as POSIX.1 says the calculation has to be done in UTC.

This means you can have date = 1970-01-02 with days since 1970-01-01 = 0, no?

/js

---

From: Carsten Bormann <[email-masked]>
Date: Wed, 1 Jul 2020 11:06:34 +0200

On 2020-07-01, at 10:44, Henk Birkholz <[email-masked]> wrote:
> 
> Both calendars and timescales can share the same epoch, though.

Not sure that statement is pedantically correct, but yes.

Grüße, Carsten

---

From: Henk Birkholz <[email-masked]>
Date: Wed, 1 Jul 2020 12:20:04 +0200

I was referring to well-known epoch concepts only, such as the beginning 
of the common era, of course. Going into all the required details 
(reference timescales) without simplification is probably unnecessary 
complexity.

Viele Grüße,

Henk

---

From: Henk Birkholz <[email-masked]>
Date: Wed, 1 Jul 2020 12:41:52 +0200

Hi Jürgen,

comments in-line.

> say that in some use cases the time zone does not matter and this is

That is an excellent example. Personally, I think that a geo-location is 
a way more stable reference to a time zone at a given point in time than 
a time zone offset associated with that geo-location (as these change 
surprisingly often over time). Having said that, associating a calendar 
day with a time zone of course supports the association of calendar day 
with my local timescale. Please see below.

> comparisons of date values can be surprising.

"in UTC" is the association of a calendar day with a timescale. If you 
do that, time-zones become relevant. If I add a calendar event to my 
schedule, I want to associate it with a local timescale / TZ, otherwise 
I will probably miss the event. That is why calendar days are often 
bundled with a time zone in an event description. It supports the 
association with a given timescale.

> This means you can have date = 1970-01-02 with days since 1970-01-01 = 0, no?

All definitions in IEEE 1003.1 are about timescales and not calendar 
days (as indicated by the use of the UTC timescale).

Viele Grüße,

Henk

---

From: Michael Richardson <[email-masked]>
Date: Wed, 01 Jul 2020 11:51:13 -0400

> comparisons of date values can be surprising.

The failure of the Nipponese to declare war on the USA on December 8, 1941
(they date of the attack on Pearl Habou^Hr in Japan...) is perhaps a better
example of failures to get the time zone right.

--
Michael Richardson <[email-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting =-

---

From: Carsten Bormann <[email-masked]>
Date: Wed, 1 Jul 2020 18:23:30 +0200

> example of failures to get the time zone right.

… and then there is V-E Day which is on 1945-05-08 everywhere except in some countries usually more or less loosely related to the Soviet Union, where it is on 1945-05-09 (even though the actual capitulation document was signed on 21:20 Central European Summer Time, which I think was 22:20 in Moscow which didn’t follow DST at the time…  
No time left to set up parades, so -05-09 it was :-).

I’m citing this as an example where a calendar date was chosen entirely by fiat, not based on the exact time of the actual event as adjusted for a specific place/time zone.  It does make sense to separate calendar dates from day-length periods anchored on a time scale, and this document is about representing calendar dates in CBOR.

Grüße, Carsten

---

From: Thiago Macieira <[email-masked]>
Date: Wed, 1 Jul 2020 15:44:21 -0700

On Wednesday, 1 July 2020 09:23:30 PDT Carsten Bormann wrote:
> I’m citing this as an example where a calendar date was chosen entirely by
> fiat, not based on the exact time of the actual event as adjusted for a
> specific place/time zone.  It does make sense to separate calendar dates
> from day-length periods anchored on a time scale, and this document is
> about representing calendar dates in CBOR.

What we need is a way to represent dates with and without a timezone 
information. If a timezone is absent, it needs to be inferred from context, 
such as birthdays as discussed, and is usually interpreted as local time.

Unix Timestamps have implied UTC (suitably un-corrected for leap seconds, 
whatever) and RFC 3339 or ISO 8601 timestamps have a way of representing a 
timezone or its absence, including dates without time.

Can you explain why we need these two new tags? Why doesn't it suffice to use 
tags 0 and 1? It is possible to use a date without a time with tag 0, after 
all.

I also question assigning a low tag number for the number-of-days-since-1970. 
That's not standardising existing practice, it's inventing a new format.

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel System Software Products

---

From: Carsten Bormann <[email-masked]>
Date: Thu, 2 Jul 2020 01:31:08 +0200

Hi Thiago,

> such as birthdays as discussed, and is usually interpreted as local time.

That may be your (and my) need, but it is not the need these two tags were defined for.

You are arguing that a date always needs to be a day-size period of time anchored on a time scale.  Yes, we need that, but giving the start time or end time of that period is a good enough proxy for this (except where you really care about both times), so we have made do with RFC 3339 (tag 0) and UNIX/Posix (tag 1).
The tag 1003 we proposed in draft-bormann-cbor-time-tag may be useful if both ends are needed; we should flesh this out.

What the tags in Mike’s and Joerg’s document try to express is the abstract notion of a calendar date.
This need comes up in documents that have a legal or social meaning (as opposed to a technical one).

> timezone or its absence, including dates without time.

Yes.  Since this is about calendar dates, RFC 3339 full-date is what is used in the new tag 1004.  Tag 100 is an analogy that abuses the UNIX epoch as a calendar epoch; this works well enough for all intents and purposes of this draft and makes the UNIX time conversion library immediately available for processing these dates.

> tags 0 and 1? It is possible to use a date without a time with tag 0, after 

Tag 0 requires conformance to the production date-time in RFC 3339; this is not very well said in RFC 7049:

   Tag value 0 is for date/time strings that follow the standard format
   described in [RFC3339], as refined by Section 3.3 of [RFC4287].

… but it becomes clear from section 3.3 of RFC 4287:

https://tools.ietf.org/html/rfc4287#section-3.3

So, no, it is not possible to use a date without a time with tag 0, unless we extend the domain of tag 0 (which the WG historically has tried not to do for tags once defined).  Tag 1004 to the rescue.

> That's not standardising existing practice, it's inventing a new format.

That is indeed valid criticism.  

With respect to using a 1+1 tag number, I think the format for tag 100 is suitably compact (the number will fit in 16 bits until the year 2149) and dates are sufficiently widely used that the use of a 1+1 tag number is justified.  

With respect to inventing things, several other epochs come to mind (I mentioned MJDs with 1858-11-17 as used in DEC VMS, MATLAB uses 0000-01-00, what ever that is supposed to mean, and there are several other attempts at defining a common era epoch, Microsoft Windows uses 1601-01-01, Microsoft Excel uses 1900-01-01 or sometimes 1904-01-01), but days since 1970-01-01 is both close enough to UNIX times to be easy to use for software developers and short enough to fit in 16 bits for a while.

Grüße, Carsten

---

From: Thiago Macieira <[email-masked]>
Date: Wed, 1 Jul 2020 17:30:39 -0700

On Wednesday, 1 July 2020 16:31:08 PDT Carsten Bormann wrote:
> You are arguing that a date always needs to be a day-size period of time
> anchored on a time scale.  Yes, we need that, but giving the start time or
> end time of that period is a good enough proxy for this (except where you
> really care about both times), so we have made do with RFC 3339 (tag 0) and
> UNIX/Posix (tag 1). The tag 1003 we proposed in draft-bormann-cbor-time-tag
> may be useful if both ends are needed; we should flesh this out.
> 
> What the tags in Mike’s and Joerg’s document try to express is the abstract
> notion of a calendar date. This need comes up in documents that have a
> legal or social meaning (as opposed to a technical one).

Sorry, you've lost me.

Why can't the new tag 1004 accept:
	2020-07-01
	2020-07-01Z
	2020-07-01-07:00
?

The GNU coreutils date tool accepts it:
$ LC_ALL=C date -d 2020-07-01
Wed Jul  1 00:00:00 PDT 2020
$ LC_ALL=C date -d 2020-07-01Z
Tue Jun 30 17:00:00 PDT 2020

> > Can you explain why we need these two new tags? Why doesn't it suffice to
> > use tags 0 and 1? It is possible to use a date without a time with tag 0,
> > after all.
> 

As a lenient parser, I've been accepting timestamps that include no time in 
tag 0. See: 
https://code.qt.io/cgit/qt/qtbase.git/tree/tests/auto/corelib/serialization/
qcborvalue/tst_qcborvalue.cpp#n425

But in "be strict in what you generate", it always includes T00:00:00.000 
time.

> With respect to using a 1+1 tag number, I think the format for tag 100 is
> suitably compact (the number will fit in 16 bits until the year 2149) and
> dates are sufficiently widely used that the use of a 1+1 tag number is
> justified.
> 
> With respect to inventing things, several other epochs come to mind (I
> mentioned MJDs with 1858-11-17 as used in DEC VMS, MATLAB uses 0000-01-00,
> what ever that is supposed to mean, and there are several other attempts at
> defining a common era epoch, Microsoft Windows uses 1601-01-01, Microsoft
> Excel uses 1900-01-01 or sometimes 1904-01-01), but days since 1970-01-01
> is both close enough to UNIX times to be easy to use for software
> developers and short enough to fit in 16 bits for a while.

Sure, but who is going to use this? I suppose it's useful for microcontrollers 
so they don't have to do string parsing, but this goes back to existing 
practice. It seems to me you have a solution in search of a problem.

I would recommend we don't add two semantically equivalent tags unless there's 
a very specific need for it. Unix Time and ISO-8601 / RFC 3339 formatted 
strings, though overlapping, clearly have uses.

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Fri, 3 Jul 2020 08:08:20 +0200

> I’m citing this as an example where a calendar date was chosen entirely by fiat, not based on the exact time of the actual event as adjusted for a specific place/time zone.  It does make sense to s…

You often associate an event with a date. If you ignore timezone, then

 (1) two systems may associate the same event with different dates and
 (2) comparisons of date values may lead to "wrong" results.

Since number of days since 1970-01-01 seems to be calculated in UTC
(the document refers to the POSIX epoch which seems to be in UTC)

 (3) a 'date' value and a 'number of days since 1970-01-01' value can
     be "inconsistent".

I think this deserves a clear warning. The -03 version has text in the
security considerations section scoped to access control decisions but
the fact that comparisons of date values and number of days since
1970-01-01 values may be surprising is not limited to access control,
i.e., I prefer to see this explicitly discussed in section 2.1,
perhaps including advice what should be done if proper comparison of
date values is desirable.

/js

---

From: Carsten Bormann <[email-masked]>
Date: Fri, 3 Jul 2020 08:29:01 +0200

> On 2020-07-03, at 08:08, Juergen Schoenwaelder <[email-masked]> wrote:
> 

Yes, that was the point of my VE-day example.

> (the document refers to the POSIX epoch which seems to be in UTC)

Yes, that is not entirely clean.  Since for many people (those west of the Atlantic) the Posix epoch falls on 1969-12-31; we need to be explicit that this is based on the calendar date of 1970-01-01.  (Using the Posix libraries still works out if you translate the calendar date into a Posix time based on UTC, *and* translate back based  on UTC as well.)  There may also be a need for a note that negative numbers are applied using the proleptic Gregorian calendar; Angela Merkel’s birthday is 100(-5844), and Charlemagne was crowned Roman Emperor on 100(-427334).

> (3) a 'date' value and a 'number of days since 1970-01-01' value can

Not sure how that can be; a common Gregorian calendar seems to be in use.

> date values is desirable.

I agree.

Grüße, Carsten

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Fri, 3 Jul 2020 08:46:52 +0200

> Not sure how that can be; a common Gregorian calendar seems to be in use.

A system may have determined a local date 1970-01-01, which in UTC is
1969-12-31 or 1970-01-01 or 1970-01-02. Hence, days since 1970-01-01
may be -1, 0, or 1, depending on how this is calculated. If the
'number of days since 1970-01-01' is always calculated in the same
unknown local timezone as the local date value, the problem goes away,
but it is likely difficult to enforce this (unless timzone information
is explicit).

/js

---

From: Carsten Bormann <[email-masked]>
Date: Fri, 3 Jul 2020 08:47:31 +0200

On 2020-07-03, at 08:29, Carsten Bormann <[email-masked]> wrote:
> 
> Charlemagne was crowned Roman Emperor on 100(-427334).

Well, maybe, 100(-426971) (tried a different date/time library; that is an amazing amount of brokenness — a year and three days off).  Maybe don’t recommend numeric day counts to historians...

Grüße, Carsten

---

From: Carsten Bormann <[email-masked]>
Date: Fri, 3 Jul 2020 09:05:50 +0200

> On 2020-07-03, at 08:46, Juergen Schoenwaelder <[email-masked]> wrote:
> 
> 1969-12-31 or 1970-01-01 or 1970-01-02.

Yes, but the UTC time is irrelevant; this is about calendar dates, and if the calendar on my wall says 1969-12-31, that is the date (represented as 100(-1)).
So I think what you are saying is that the current calendar date at the same instant in time (*) may be different in different parts of the world?
That’s why we want to get away from anchoring these dates on a time scale.

> Hence, days since 1970-01-01

Doing this conversion in a time zone is dangerous; you’ll need to make sure that you properly round off the daylight savings time transitions.  Better to always to this in world time (UTC), which is then benign (unless your libraries have a bug, see previous message).

Counting calendar sheets ripped off the wall is rather unambiguous, though.

The problems that you are alluding to come from transitioning between the calendar day domain and the time anchored on a time scale domain; additional problems are caused with this when the time involves time zones that vary in world time offset.

I think we need firmer text that makes clear that the dates covered by tags 100 and 1004 are calendar dates, and that conversions between these and times on a timescale can be done, but require attention and usually some additional context.

Grüße, Carsten

(*) No, I’m not opening the relativistic can of worms.

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Fri, 3 Jul 2020 12:32:12 +0200

On Fri, Jul 03, 2020 at 09:05:50AM +0200, Carsten Bormann wrote:

[...]

> The problems that you are alluding to come from transitioning between the calendar day domain and the time anchored on a time scale domain; additional problems are caused with this when the time in…

You like to view a date as something entirely detached from the notion
of time. I am not sure what the use cases for this are, in particular
for computers.

I can see, however, a number of use cases where a date is associated
with a specific event and in these situations the date value is
ambiguous since multiple systems rightfully may assign different dates
to the same event (the same point in time). Hence, code comparing date
values or making calculations with them has to be careful that
surprises may happen.

/js

PS: There are even events where there is no natural time zone that can
    be associated with the event, like the first step on the moon.

---

From: Carsten Bormann <[email-masked]>
Date: Fri, 3 Jul 2020 14:11:00 +0200

>    be associated with the event, like the first step on the moon.

(For those who weren’t there when it happened:)

Indeed, Monday, 1969-07-21T02:56:15Z.

Most Americans will tell you Sunday 1969-07-20 for the first steps.   The exact time was actually specifically chosen to occur on prime time TV in the US (and then was slightly delayed, but managed to stay in window), which spans several time zones, which all have this on 1969-07-20.

Yes, I agree we should have some text on this (not the moon landing, but the issues in converting between calendar dates and times anchored on time scales).

Grüße, Carsten

---

From: Jim Schaad <[email-masked]>
Date: Tue, 7 Jul 2020 21:46:27 -0700

Mike,

Based on the messages that I have seen, I would suggest the following actions:

Create a new section dealing with the following: 
a) a definition of what calendar day means
b) a definition of a term other than Unix Epoch to be used as the basis.  This  is a point in time rather than a calendar day so having this as the basis point seems to be generation frisson.  It would appear that it is better to use 1970-01-01 as a POSIX calendar date epoch.
c) Guidance on how to use two points in time to compute a calendar day count.
d) Information on why it is a bad idea or how to compare a calendar date and a point in time.
e) Guidance on how to compare two calendar dates (this should be easy).

Jim

> -----Original Message-----
> From: CBOR <[email-masked]> On Behalf Of Carsten Bormann
> Sent: Friday, July 3, 2020 5:11 AM
> To: Juergen Schoenwaelder <[email-masked]>
> Cc: [email-masked]; Michael Richardson
> <[email-masked]>; [email-masked]
> Subject: Re: [Cbor] draft-ietf-cbor-date-tag-02 - handling of time zone offsets
> 
> Most Americans will tell you Sunday 1969-07-20 for the first steps.   The exact
> time was actually specifically chosen to occur on prime time TV in the US (and
> then was slightly delayed, but managed to stay in window), which spans several
> time zones, which all have this on 1969-07-20.
> 
> Yes, I agree we should have some text on this (not the moon landing, but the
> issues in converting between calendar dates and times anchored on time
> scales).
> 
> Grüße, Carsten
>

---

From: Carsten Bormann <[email-masked]>
Date: Wed, 8 Jul 2020 07:19:58 +0200

> On 2020-07-08, at 06:46, Jim Schaad <[email-masked]> wrote:
> 
> Mike,
> 

Let me try...

> a) a definition of what calendar day means

A calendar day is a day on a (here: the Gregorian) calendar.
The specific mapping of calendar days on civil time (here: UTC) is established by convention outside the scope of the date tags.

> b) a definition of a term other than Unix Epoch to be used as the basis.  This  is a point in time rather than a calendar day so having this as the basis point seems to be generation frisson.  It w…

1970-01-01 was chosen as the epoch for counting calendar days for the date tags because it is convenient on systems that have Posix date/time libraries available.

> c) Guidance on how to use two points in time to compute a calendar day count.

Well, that goes deep into date/time library APIs.
But, usually, these APIs allow you to apply a timezone to a point in time and retrieve a calendar day and a time-of-day.
By zeroing out the time-of-day, time deltas can be produced that, divided by 86400 and *rounded* to the nearest integer give you a calendar day count.

Watch out when using historical dates (the Gregorian calendar has a discontinuity in 1582, which was integrated into the civil calendars either immediately or later, say, 1752, 1753, … or 1923 if you are in Greece); make sure these are actually on the (proleptic) Gregorian calendar already.  Also, historically, the calendar date changed at sunrise, noon (astronomical day/Julian day number), or sunset on some calendars, and the year number on March 25th.  Again, not a problem as long as all dates are on the proleptic Gregorian calendar and your date/time libraries aren’t broken (which many are for historical dates).

> d) Information on why it is a bad idea or how to compare a calendar date and a point in time.

A calendar date is not anchored on a timescale, only adding timezone information does that.

> e) Guidance on how to compare two calendar dates (this should be easy).

If you have the day number (tag 100), that is easy.
If you have the RFC 3339 full-date, go through a date/time library (using UTC as a time zone is the simplest approach).

Amazing.  I would not have thought that talking about calendar dates would evoke all this complexity...

Grüße, Carsten

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 16 Jul 2020 15:37:21 +0200

Thanks for adding new text to -04. I am, however, not sure the text is
already resolving all issues.

- I do not understand why you reference IEEE Std 1003.1, 2013 Edition
   [POSIX.1] time epoch 1970-01-01T00:00:00Z UTC if you then say that
   the timezone is irrelevant. If the timezone is irrelevant, you can
   simplify things:

   OLD

   The epoch chosen for the second tag, which represents days since the
   Gregorian calendar date 1970-01-01, is related to the IEEE Std
   1003.1, 2013 Edition [POSIX.1] time epoch 1970-01-01T00:00:00Z UTC
   only insofar as both contain the date 1970-01-01.  This should not be
   construed as indicating that dates using this tag represent either a
   specific time of day and/or time zone.

   NEW

   The epoch chosen for the second tag, which represents days since the
   Gregorian calendar date 1970-01-01.

- In the section Comparing Dates, I like to see a clear statement that
  dates generated by systems in different timezones for the same event
  may not compare for equality.

- I do not understand section 1.3. Perhaps you wanted to say that the
  representation of date and time values is already defined in section
  2.4.1 of RFC 7049? (Of course, one could ask the question why you now
  introduce a tag for date values but not at the same time also a tag
  for time values.)

/js

---

From: Mike Jones <[email-masked]>
Date: Thu, 16 Jul 2020 15:58:43 +0000

Replies inline, prefixed by "Mike>"...

-----Original Message-----
From: Juergen Schoenwaelder <[email-masked]> 
Sent: Thursday, July 16, 2020 6:37 AM
To: [email-masked]; [email-masked]
Subject: [EXTERNAL] Re: draft-ietf-cbor-date-tag-02 - handling of time zone offsets

Thanks for adding new text to -04. I am, however, not sure the text is already resolving all issues.

   OLD

   NEW

Mike> Given that many developers know that the UNIX/POSIX Epoch is 1970-01-01T00:00:00Z, others would think it is odd if we *don't* reference it.  I believe the current reference text strikes an appropriate balance, saying how they are and are not related.

Mike> OK

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.

/js

---

From: Carsten Bormann <[email-masked]>
Date: Thu, 16 Jul 2020 18:10:45 +0200

> 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 p…

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.

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)

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.

(“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

---

From: Henk Birkholz <[email-masked]>
Date: Thu, 16 Jul 2020 19:48:43 +0200

> 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

> 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 bein…

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?

---

From: Carsten Bormann <[email-masked]>
Date: Fri, 17 Jul 2020 09:02:41 +0200

> On 2020-07-16, at 19:48, Henk Birkholz <[email-masked]> wrote:
> 

draft-bormann-cbor-time-tag, I’d say.

The terminology being used in draft-ietf-cbor-date-tag is self-explanatory, so no need for a discussion there.

This is really more about *not* using the *wrong* terminology.

Grüße, Carsten