Re: [Sedate] A syntax proposal: floating and future times

[Bron Gondwana <[e-mail]>]

On Tue, Nov 9, 2021, at 13:07, Justin Grant wrote:
> I see two common themes on the thread above: A) need to carefully name and define use cases we're concerned about; B) carefully document objections to previous proposals to address those use cases. Here's an attempt to cover those two things by summarizing below what I heard above. Let me know what you think.
> 
> *Name and define use cases we're concerned about (names are placeholders)*
> 
>  * *"Timestamp"* - What RFC 3339 specifies. It's an unambiguous time-from-epoch numeric value. The offset must be included, either a Z or a numeric offset from UTC.
>  * *"DateTime"* - a "floating" date/time string that does not include any reference to a time zone or offset. This is the same data model (with different syntax) as is used by Form #1 of the data model for calendar meetings in RFC 5545 3.3.5 <https://datatracker.ietf.org/doc/html/rfc5545#section-3.3.5>.
>  * *"Z Timestamp"* - A timestamp string that makes no assertions about the local time when the timestamp when it was captured. This is the same data model as Form #2 of calendar meetings defined in RFC 5545 3.3.5 <https://datatracker.ietf.org/doc/html/rfc5545#section-3.3.5>.

When naming I'd probably spell this out as 'Zulu Timestamp'.

>  * *"Numeric Offset Timestamp"* - A timestamp string that combines a date/time string with a numeric offset. Unlike Z Timestamps, this format allows recording the local time when the timestamp was captured.
>  * *"Timestamp + Extensions"* - A timestamp with optional extensions that may describe its time zone as well as other extensions like calendars.  Note: it seems like calendars don't cause any problems in this thread, so I'll ignore them in the bullet points below.
>  * *"DateTime + Offset + Timezone"* ( *"DTOTZ"* for short?) - A string that combines the syntax of a Numeric Offset Timestamp with a time zone extension. The timestamp portion of the string may or may not match the semantics of RFC 3339 depending on an obscure corner case: if the timestamp is in the future or the recent past, then it's rare but possible for the offset to change so that evaluating the same timestamp in that timezone will yield a different local date/time. In those cases, the receiver must have a way to resolve the conflict, either by specifying which one "wins" or specifying "mutual consent of communicating parties".  I believe this is case (b) in the thread above.  This format has not been standardized, but it's been used for many years by Java and other libraries and Temporal is planning to use it too.

Why not just spell this as "Timestamp + Timezone" or "Zoned Timestamp"

>  * *"DateTime + Timezone"* (aka *"DTT"*?) - a DateTime combined with the time zone used to convert that floating DateTime into a timestamp. No offset is stored, so the Timestamp must be calculated by the receiver.  Note that during backwards DST transitions, the same DateTime will repeat twice. So there must be a way to resolve the ambiguity.  This case corresponds to the data model of Form #3 of RFC 5545 3.3.5 <https://datatracker.ietf.org/doc/html/rfc5545#section-3.3.5>.  I believe this is case (b) in the thread above. Temporal also supports this format.  This is perhaps the most important format for calendaring apps because normal end-users create events in local time and a time zone; calendar UIs almost never expose technical details like offsets or repeated hours during a DST transition.

And of course "Zoned Datetime".

> Did I get the cases right?  Did I miss anything important?
> 
> *2) Objections/concerns/questions to address those use cases.*
> 
> I'll do my best to document what I've heard above. I suspect this list may be incomplete.
>  1. *Should this RFC allow strings that match RFC 3339 syntax without matching RFC 3339 semantics?*  Can existing RFC 3339-compliant code strip any annotations and use the resulting string as a timestamp?  Or will old code need to be re-tooled to account for new behavior? From reading the comments above, this seems to be the primary objection from multiple commenters. Correct?
>  2. *Is a DTOTZ a timestamp according to RFC 3339?*  Calling this an "almost timestamp" above may be overstating the deviation, because this string *does* represent an unambiguous instant on the timeline when the timestamp was captured. An RFC 3339-compliant application that doesn't know about time zones can safely use this format. So I think the answer to this concern is "yes". Anyone disagree?
>  3. *What should receivers do if offset and time zone conflict in a DTOTZ?* The extra metadata added by the time zone exposes potential ambiguity that the receiver will have to deal with in the (rare) case where time zone rules have changed between when the timestamp was stored and when it is being interpreted, or if the communicating parties are using a different TZDB version. What should the receiver do if there's a conflict? Should the timestamp win, yielding a different local time? (This breaks calendar applications, FWIW.) Or should the local time win, yielding a different timestamp than receivers that only know about RFC 3339?  Or should the RFC punt on this case and leave it up to the communicating parties to work it out, as ISO 8601 does in a lot of similar cases like the number of decimal digits allowed?  Temporal is in the "leave it up to communicating parties" camp, but IMHO the only really bad outcome would be standardizing the "DateTime MUST win" behavior because that would force receivers to behave differently from RFC 3339 which seems undesirable and would probably trigger objection (1) above.

This is the case for which I want the creator of the item to set a preference.  I don't particularly care WHICH syntax so long as it is:
* unambiguous for a machine to parse
* easy for a human to understand
* hard to get wrong (fewest possible invalid things that look correct, fewest weird corner cases for generating software to deal with)

>  1. *How should senders communicate to receivers that they want the Timestamp or the DateTime to "win" if there's a conflict?* To avoid the "conflict" case above, I've heard the following options above:
>    * a) Senders should use a Z Timestamp + TimeZone string if they want the Timestamp to win, and send a DTT if they want the DateTime to win

I feel like this fails the "easy to get right, hard to get wrong" thing.  People don't treat 'DatetimeZ' as being different from 'Datetime+00:00' - and even more importantly, libraries don't.  So you'll run into the problem that data gets lost when using what would otherwise have been sensible toolchains.

>    * b) Senders can add another extension for this purpose, e.g. [offset=use] or [offset=ignore].
>    * c) Overload the time zone annotation, e.g. [tz=Asia/Tokyo] means "DateTime wins" but  [Asia/Tokyo] means "Timestamp wins"
>    * d) N/A, because our answer to (3) will preclude the possibility of conflicts by specifying either the timestamp or the DateTime will always win.
>    * Are there any other options?
>  1. *What should be the syntax of a DTT string? * I've heard the following suggestions above:
>    * a) Omit the offset. This is what Temporal prefers, BTW.

It's what I prefer too, but it does meant that the 'Datetime' construct is NOT an RFC3339 production.  On the plus side, it is unambigous, easy for humans to read, and hard to get wrong.

>    * b) Use a J offset. 
>    * c) Use a special time zone annotation, e.g. [tz=Asia/Tokyo] as opposed to [Asia/Tokyo], that means to interpret the "timestamp" string not as a timestamp but instead using some other semantics.  My sense from reading the comments above is that this option would trigger concern (1) above so would elicit a lot of opposition. 
>    * Are there other options?

BUT - I do also like the idea of having an offset hint even if it's a "Zoned Datetime" because it helps debug what the senders belief was, and it also nicely disambiguates the daylight savings repeat.

>  1. *Even if all the concerns above are addressed, should DTT be specified at all?* DTT is probably the primary data model for calendar meetings and other end-user UI "time in my time zone" cases. Furthermore, DTT strings are clearly *not* Timestamps because they lack an offset, so there should be no backwards-compatibility issues.  If there are no backwards-compatibility issues, then are there *other* objections to specifying DTT strings?
> Did I miss any other objections? Please feel free to add others or correct me if I got something wrong above. Obviously I have opinions about better vs worse answers to the questions above, but at this point I'm mostly concerned with making sure we understand the issues involved and where various folks stand on those issues. Thanks!

I think it should be.  I'm happy with doing a separate document for it, but I wouldn't want to repeat all the work in this document, so we'd basically want to define all the extensions in a way that's easily referenced from a new document that defines naked 'Datetime' values to be used with the same extensions.

Bron.

--
  Bron Gondwana, CEO, Fastmail Pty Ltd
  [e-mail]