Subject: [Sedate] Comments on draft-ryzokuken-datetime-extended-02

From: "Neil Jenkins" <[email-masked]>
Date: Fri, 30 Jul 2021 11:55:13 +1000

Hi

I have a couple of things I'd like to discuss with this draft:

*1. No PlainDateTime definition*

The Temporal proposal has a PlainDateTime format that is just a wall clock date/time with no offset/time zone information attached. This is serialised <https://tc39.es/proposal-temporal/docs/> in the current Temporal spec as `YYYY-MM-DDTHH:MM:SS` – which is great, this is exactly the same serialisation <https://www.rfc-editor.org/rfc/rfc8984.html#name-localdatetime> we use in RFC8984 for JSCalendar, but it's not actually defined in RFC3339, because RFC3399 is just for timestamps (absolute instants in time). I had thought that the goal of this document was to standardise serialisations for other commonly needed date formats, not just timestamps. If the goal of the TC39 WG is to use standardised serialisations for the new objects, then this needs to be included too.

*2. Time zones can be added to any offset?*

Time zone definitions are political and can and do change at very short notice. For any kind of future time, you often want to store the wall clock time and the time zone name in which it will occur; the exact instant in UTC may change. The current definition requires an offset to be included as well. This is OK in that it does allow you to disambiguate when there are two different instants with the same wall clock time (which can happen at DST transitions), but there are two issues:
 1. It currently doesn't require the offset to be that ZonedDateTime in the time zone. (Or I missed it if so.) This is critical I think.
 2. It doesn't define semantics or even guidance for what to do if the time zone data changes and the offset included is not a valid offset in the given time zone with that wall clock time. How should that be interpreted?

*3. No names for specific combinations*

It's very helpful if we can have separate names for specific variants, ideally with their own section number. For example, in another RFC you might specify that "this is a date in the ZonedDateTime format defined by RFC XXX, Section YYY". This is perhaps nice-to-have rather than critical, but I think for something widely referenced (like this is likely to be) it can help other spec writers to be much clearer about what is conformant with their use case.

Neil.

---

From: Carsten Bormann <[email-masked]>
Date: Fri, 30 Jul 2021 14:49:55 +0200

I think sedate needs to make up their mind whether they are a timestamp group (RFC 3339 and all that) or a calendaring group (handle future dates based on contextual inputs that may not be available or not available yet).  It can’t be both.

Grüße, Carsten

> On 2021-07-30, at 03:55, Neil Jenkins <[email-masked]> wrote:
> 
> Hi
> 
> 1. No PlainDateTime definition
> 
> The Temporal proposal has a PlainDateTime format that is just a wall clock date/time with no offset/time zone information attached. This is serialised in the current Temporal spec as YYYY-MM-DDTHH:MM:SS – which is great, this is exactly the same serialisation we use in RFC8984 for JSCalendar, but it's not actually defined in RFC3339, because RFC3399 is just for timestamps (absolute instants in time). I had thought that the goal of this document was to standardise serialisations for other commonly needed date formats, not just timestamps. If the goal of the TC39 WG is to use standardised serialisations for the new objects, then this needs to be included too.
> 
> 2. Time zones can be added to any offset?
> 
> 	• It currently doesn't require the offset to be that ZonedDateTime in the time zone. (Or I missed it if so.) This is critical I think.
> 	• It doesn't define semantics or even guidance for what to do if the time zone data changes and the offset included is not a valid offset in the given time zone with that wall clock time. How should that be interpreted?
> 
> 3. No names for specific combinations
> 
> -- 
> Sedate mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sedate