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

From: Ujjwal Sharma <[email-masked]>
Date: Mon, 2 Aug 2021 11:09:43 +0530

On 30/07/2021 18.19, Carsten Bormann wrote:
> 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.

It was this exact confusion that led us to calext at the beginning.
After spending a decent amount of time rechecking our priorities and
chartering sedate, I think the answer is clear: sedate is a timestamp
group as mentioned in the charter.

That said, even though we might not be doing calendaring stuff directly
here, we can still ensure that our work addresses the use-cases of
calendaring groups (like calext), right?

Ujjwal

-- 
Ujjwal "Ryzokuken" Sharma (he/him)

Compilers Hacker, Node.js Core Collaborator and Speaker

---

From: Ujjwal Sharma <[email-masked]>
Date: Mon, 2 Aug 2021 13:46:15 +0530

On 30/07/2021 07.25, Neil Jenkins wrote:
> *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
> ...
> timestamps. If the goal of the TC39 WG is to use standardised
> serialisations for the new objects, then this needs to be included too.

Good point! That said, I'm not sure if it would be super
well-received... Maybe we can do a completely distinct RFC3339-like
format including all the different non-instant formats? Could it be done
under calext (I doubt the current charter of sedate would permit it)? We
could also modify the current draft so that the same extension format
could be used for both instants and non-instants (as expected by
Temporal anyway).

Either way, I'd be happy to collaborate on such an effort, but I'll
raise this to the rest of Temporal champions ASAP to see what they think
of it as well.

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

No it doesn't. I think someone mentioned the case of storing the instant
and time zone separately and constructing the string from those, which
would be significantly more complicated with this requirement.

In Temporal, we tried to use this mental model: the instant isn't being
*interpreted in* the data (the timezone, calendar etc) but it is being
*projected to* it. By this rationale, any instant can be projected into
your timezone, it doesn't need to be already in it. This seems more
obvious for calendars, perhaps. The date and time format obviously
conform to the conventions of the ISO calendar (based on Gregorian) but
they can be projected to whichever calendar you specify, like Hebrew or
Buddhist...

That said, I feel that the format can be as permissive as possible while
the implementations can restrict input that it does not deem correct.

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

In the current state of the draft, since any offset can go with any time
zone, I didn't feel that this was necessary. Implementations that find
this mismatch situation non-ideal may choose to react with it
appropriately. I think there would be good rationales for both rejecting
the values outright and handling it gracefully.

> *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
> ...
> likely to be) it can help other spec writers to be much clearer about
> what is conformant with their use case.

This sounds like great advice, especially paired with the whole
discussion we had in 111 about documenting use-cases. I'll try to get a
PR running to incorporate both pieces of advice, if that sounds okay.
Would you volunteer to review it? :D

Thanks for your comments!

Best,
Ujjwal

---

From: "Neil Jenkins" <[email-masked]>
Date: Tue, 03 Aug 2021 10:26:34 +1000

On Mon, 2 Aug 2021, at 18:16, Ujjwal Sharma wrote:
> under calext (I doubt the current charter of sedate would permit it)?

Right. I didn't pay much attention between this project being brought to dispatch and the chartered working group being produced, and it clearly ended up quite different to what I expected.

I think this is worth documenting somewhere; it's a de facto standard because it's the obvious adaptation from 3339, but it's still worth having an actual RFC to point to and reference.

> *projected to* it.

Yeah, I can see that mental model. I still feel a slight cognitive dissonance thinking about it that way for future times, but maybe that's just me. I guess there are three different types of semantics you might want to serialise:
 * Instant in time, project into time zone (best to use `Z` – UTC – for timestamp to convey this intention).
 * Time in time zone with expected offset (if doesn't match, application may need to do something to resolve; in calendaring, the local time is generally considered authoritative).
 * Time in time zone, no expected offset given (we know the time zone is going to take precedence over the offset, so just calculate the offset when we need it from the time zone).
This format aims to cover (1) and the syntax for (2), although semantics would require further definition in the referencing spec.

> zone, I didn't feel that this was necessary.

Yes, I think I agree; if we say you can do this, then it doesn't make sense to define these semantics here.

> Would you volunteer to review it? :D

Tentatively yes. :)

Neil.

---

From: Ujjwal Sharma <[email-masked]>
Date: Tue, 3 Aug 2021 12:50:42 +0530

CCing Bron here for more visibility

On 03/08/2021 05.56, Neil Jenkins wrote:
> I think this is worth documenting somewhere; it's a de facto standard
> because it's the obvious adaptation from 3339, but it's still worth
> having an actual RFC to point to and reference.

I like the general idea here, is this something that is permitted by the
calext charter? Something along the lines of "Alternate timestamp
formats for calendaring and other applications"?

Ujjwal

---

From: "Bron Gondwana" <[email-masked]>
Date: Tue, 03 Aug 2021 19:21:56 +1000

I believe so as long as define what we're doing and put some SHOULD NOT be used for times in the past language at around it.

And as was mentioned in the session, we definitely want to give names for all the different formats which are absolutely clear and distinct.

Bron.

On Tue, Aug 3, 2021, at 17:20, Ujjwal Sharma wrote:
> Sedate mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sedate
> 

--
  Bron Gondwana, CEO, Fastmail Pty Ltd
  [email-masked]

---

From: Ujjwal Sharma <[email-masked]>
Date: Tue, 3 Aug 2021 18:32:46 +0530

On 03/08/2021 14.51, Bron Gondwana wrote:
> I believe so as long as define what we're doing and put some SHOULD NOT
> be used for times in the past language at around it.
> 
> And as was mentioned in the session, we definitely want to give names
> for all the different formats which are absolutely clear and distinct.

Sounds great!

Would either you or Neil like to kick off an ID for this or should I?

Ujjwal

---

From: "Bron Gondwana" <[email-masked]>
Date: Tue, 03 Aug 2021 23:16:14 +1000

> Would either you or Neil like to kick off an ID for this or should I?

I think that the naming of all the components of the extended date can be done in the existing document, including what's currently the RFC3339 date part.  It just needs a more generic name for "anything in that location" and then more specific names for "UTC DateTime" (with trailing Z), "Offset DateTime" (datetime with [+-]XX:XX) and "Floating DateTime" (without either Z or [+-] part).

I'll do another "call for authors" to see if someone wants to co-author that draft with you :)

As a working group chair, I'm a bit cautious about taking on any documents that might be contentious as an author myself due to the risk of conflict of interest issues... though of course having another Fastmail employee as author also raises questions when taken in conjunction with my role in the company!

Cheers,

Bron.

---

From: Justin Grant <[email-masked]>
Date: Tue, 3 Aug 2021 12:00:08 -0700

> >     in the given time zone with that wall clock time. How should that be

On the Temporal side, we've spent an embarrassingly long time pondering
this "time zone changes in the future" case. Here's where these discussions
ended up:

   - The most common time when developers learn that their code is broken
   due to a future time zone change will be *after* they've already stored
   a future time data using the outdated timezone offset. In other words, by
   the time the median developer learns that there's a problem, they've
   already stored invalid data. Expecting busy developers worldwide to
   anticipate rare problems like this is probably unrealistic.
   - Therefore, our top priority was ensuring that the default case would
   store enough data for developers to handle the future offset change however
   they see fit. So the default serialization of ZonedDateTime includes three
   things: the local time, the offset, and the time zone ID. This ensures that
   a lossless conversion to the new time zone rules is possible because the
   original local time is recorded, as is the timestamp and the time zone.
   - Deserializing an offset that's now invalid will, by default, throw an
   exception. This will alert developers that there's a problem, instead of
   silently picking a default which may be wrong.
   - When developers run into this exception, they can decide whether the
   local time or the timestamp should be retained. When deserializing, there's
   an offset option (see
   https://tc39.es/proposal-temporal/docs/zoneddatetime.html#from) to
   control how this ambiguity should be resolved: keep the local time the same
   but change the offset; keep the timestamp the same but change the local
   time; or throw. (There's also a "best effort" option that's used in cases
   where you're changing the local time but not the date. This allows changing
   the minutes field from :30 to :45 in the hour repeated by DST ending
   without losing the correct offset for that local time.)
   - If developers do anticipate this problem, they can choose to serialize
   the ZonedDateTime without the offset (which means "use the current time
   zone rules") or they can choose to serialize using "Z" which means ("use
   the timestamp even if the new local time is different"). This is one of the
   reasons why we support variation (offset present, missing, or "Z") in the
   serialization format, because it allows developers to assert how to handle
   cases where the time zone rules change.

Sorry for such a long explanation, but hopefully this context is helpful.

Cheers,
Justin

On Tue, Aug 3, 2021 at 6:16 AM Bron Gondwana <[email-masked]> wrote:

> I think that the naming of all the components of the extended date can be
> done in the existing document, including what's currently the RFC3339 date
> part.  It just needs a more generic name for "anything in that location"
> and then more specific names for "UTC DateTime" (with trailing Z), "Offset
> DateTime" (datetime with [+-]XX:XX) and "Floating DateTime" (without either
> Z or [+-] part).
>
> As a working group chair, I'm a bit cautious about taking on any documents
> that might be contentious as an author myself due to the risk of conflict
> of interest issues... though of course having another Fastmail employee as
> author also raises questions when taken in conjunction with my role in the
> company!
>
> Cheers,
>
> Bron.
>
> --

---

From: "Neil Jenkins" <[email-masked]>
Date: Wed, 04 Aug 2021 10:50:10 +1000

On Wed, 4 Aug 2021, at 05:00, Justin Grant wrote:
> On the Temporal side, we've spent an embarrassingly long time pondering this "time zone changes in the future" case. Here's where these discussions ended up

I think this all sounds great, and absolutely correct. I guess I'm just trying to figure out the scope of this RFC document; I initially thought some of these semantics would be worth documenting, at least as a discussion, because they *do* take a lot of time to get right and it might be helpful to guide other users of this format in the future. However, if that's not the scope of the charter we ended up on, so be it.

I still think that simply documenting and naming the subcomponents so they can be referenced by other specs (including Temporal for the PlainDateTime serialisation etc., as discussed before) is very worthwhile and doesn't change the scope of this document.

>  * If developers do anticipate this problem, they can choose to serialize the ZonedDateTime without the offset 

Out of interest, do you mean manually, or is there some way of doing this directly with Temporal? I didn't see this in a glance through the documentation (the `toJSON` method always includes an offset, yes?).

Neil.

---

From: Justin Grant <[email-masked]>
Date: Tue, 3 Aug 2021 18:01:38 -0700

*(sorry Neil for the spam, but I forgot to reply-all the first time)*

>    - If developers do anticipate this problem, they can choose to
>    serialize the ZonedDateTime without the offset
>
> Out of interest, do you mean manually, or is there some way of doing this
> directly with Temporal? I didn't see this in a glance through the
> documentation (the toJSON method always includes an offset, yes?).

There are options on the toString method to control various parts of the
output. See
https://tc39.es/proposal-temporal/docs/zoneddatetime.html#toString.

toJSON is intended to be used with JSON.stringify which doesn't have a way
to transmit options, so it doesn't accept any options. The implementation
of toJSON just calls toString with no options. For custom behavior, use
toString.

On Tue, Aug 3, 2021 at 5:50 PM Neil Jenkins <[email-masked]> wrote:

> ended up
> I think this all sounds great, and absolutely correct. I guess I'm just
> trying to figure out the scope of this RFC document; I initially thought
> some of these semantics would be worth documenting, at least as a
> discussion, because they *do* take a lot of time to get right and it
> might be helpful to guide other users of this format in the future.
> However, if that's not the scope of the charter we ended up on, so be it.
>
> I still think that simply documenting and naming the subcomponents so they
> can be referenced by other specs (including Temporal for the PlainDateTime
> serialisation etc., as discussed before) is very worthwhile and doesn't
> change the scope of this document.
>
>
>    - If developers do anticipate this problem, they can choose to
>    serialize the ZonedDateTime without the offset
>
>
> Out of interest, do you mean manually, or is there some way of doing this
> directly with Temporal? I didn't see this in a glance through the
> documentation (the toJSON method always includes an offset, yes?).
>
> Neil.
> --
> Sedate mailing list
> [email-masked]

---

From: Carsten Bormann <[email-masked]>
Date: Wed, 4 Aug 2021 08:33:01 +0200

On 3. Aug 2021, at 21:00, Justin Grant <[email-masked]> wrote:
> 
> When developers run into this exception, they can decide

That is one way to handle this: take the resolution of the inconsistency from the context of the recipient.

One other way would be to indicate the intention of the sender in the interchanged item.
I think this is what sedate should be interested in.

Grüße, Carsten

---

From: Martin J. Dürst <[email-masked]>
Date: Wed, 4 Aug 2021 16:44:20 +0900

> Sorry for such a long explanation, but hopefully this context is helpful.

I think it is very helpful. And if we end up with such a format (among 
else), then I think it's crucial that this explanation is part of the 
spec, because otherwise, we end up with all kinds of different 
interpretations.

Regards,   Martin.