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

[Justin Grant <[e-mail]>]

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

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.
   4. *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
      - 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?
   5. *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.
      - 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?
   6. *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!

Cheers,
Justin


On Mon, Nov 8, 2021 at 4:59 PM Martin J. Dürst <[e-mail]>
wrote:

> Hello Shane, others,
>
> On 2021-11-09 00:41, Shane Carr wrote:
> > Two issues about storing a floating time with a time zone but not an
> offset
> > are (1) ambiguities around summer time transitions and (2) summer time
> > rules are subject to change.  Storing an offset along with the time zone
> > solves these issues, but introduces another: should the offset or the
> time
> > zone "win" in the case of a conflict?
>
> To be more precise, with (1), are you referring to the 'doubled' one
> hour when switching back from summer time to normal time that results
> because clocks have to be switched back by one hour? So as a specific
> example, this would allow to distinguish
>
> 2021-10-31T02:30:00+02:00[Europe/Zurich] (before setting clocks back)
> and
> 2021-10-31T02:30:00+01:00[Europe/Zurich] (after setting clocks back)
> which both actually existed. In this case, wouldn't it be more
> straightforward to just denote these two instants in time as
> 2021-10-31T02:30:00+02:00 and 2021-10-31T02:30:00+01:00 ?
>
> Also, with (2), are you referring to cases where the rules suddenly
> change on short notice? In that case, is the purpose of having both
> pieces of information to distinguish between "this is according to the
> old rules, before the sudden rule change" and "this is according to the
> new rules" ? Again, wouldn't it be easier to just have the actual
> information?
>
>
> > In Temporal, we solve this via an API option
> > <https://tc39.es/proposal-temporal/docs/zoneddatetime.html#from> called
> > "offset" to declare the intent.  There is a further "disambiguation"
> option
> > to handle the summer time conflict.
> >
> > However, would it be useful if there were an annotation to declare the
> > intent within the datetime string?  Something like
> >
> > 2022-11-26T20:00:00+11:00[Australia/Melbourne][offset=ignore]
> > 2022-11-26T20:00:00+11:00[Australia/Melbourne][offset=prefer]
>
> Why give two (possibly conflicting) pieces of information to then say
> which one actually counts? Isn't it much easier to just give the
> information you want to be used, and leave the other part out?
> So insteaf of
>
>  > 2022-11-26T20:00:00+11:00[Australia/Melbourne][offset=ignore]
> just write 2022-11-26T20:00:00[Australia/Melbourne],
> and instead of
>  > 2022-11-26T20:00:00+11:00[Australia/Melbourne][offset=prefer]
> just write 2022-11-26T20:00:00+11:00 ?
>
> Regards,   Martin.
>
> --
> Sedate mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/sedate
>