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

[Justin Grant <[e-mail]>]

What I'm hearing from Bron (which I agree with) is that there should be a
standardized syntax for floating times like "10:00AM on 20 January 2025 in
Melbourne".  This is how calendaring apps will store future meetings. We
can bikeshed on specific syntax, but the high order bit is that this use
case is very important for interchange.

But there's also what Neil and Carsten are saying, which is that floating
times are "not timestamps", meaning they're not interchangeable with a
single number indicating time since eopch. This is also correct, and
forcing all timestamp-reading software to also know about floating times
seems bad. So I can understand why other IETF folks may be concerned about
backwards compat and would want the new RFC to be a strict superset of
RFC3339 syntax in order to make it easier to port software to the new RFC.

I'd suggest that one way to achieve both camps' goals might be to split the
RFC text into two buckets (I'm assuming sections in the same document):

*1. Timestamps + annotations*.

   - Superset of RFC 3339; 100% backwards-compatible syntax and semantics
   if the annotations are stripped off.  Interchangeable with a single numeric
   since-epoch value. For backwards-compat reasons, Z or numeric offset is
   always required in the string.
   - Timezones and other extension syntax is specified here.
   - Includes a decision about how to treat conflicts between timezone and
   (non-Z) offsets if both are present.  Choices include: always reject;
   always keep the instant unchanged; always keep local time unchanged; or "by
   mutual agreement of the communicating parties" because desired behavior
   varies by use case.

*2. Subsets of "timestamps + annotations".*  Like ISO 8601 defines subsets
of its syntax for different use cases, so can we. "10:00AM on 20 January
2025 in Melbourne" represents most calendar meetings in the world and is a
subset with every field except offset. We can bikeshed on the string syntax
for this subset, as long as it's *not* RFC 3339 because that will bring up
those backwards-compat concerns noted above.  This section could be
extended further in a later revision with more subsets, e.g. Time + Time
Zone ("9:00AM in Berlin").

I'm not suggesting different content, only a slightly different way to talk
about the same work that might be less concerning to folks whose top
priority is backwards compat. and/or precision around what is and is not a
timestamp.

Cheers,
Justin


On Mon, Nov 8, 2021 at 1:06 AM Bron Gondwana <[e-mail]> wrote:

> On Mon, Nov 8, 2021, at 18:40, Justin Grant wrote:
>
> *Changes to zone offsets*
>
>
> My understanding is that there's three use cases:
> 1. The sender wants to keep the instant fixed, even if the offset of the
> time zone has changed (this may result in a different local time than what
> was originally captured)
> 2. The sender wants to keep the local time fixed, even if the offset of
> the time zone has changed (this may result in a different instant than what
> was originally captured)
> 3. The sender has no opinion. It will send both the offset and the time
> zone to the receiver, and it wants the receiver to decide what to do if the
> offset of the time zone has changed.
>
> Here's how Temporal is currently (modulo whatever we decide here in
> SEDATE!) planning to handle these three cases:
> 1. Keep instant fixed by specifying a Z offset with a time zone
> annotation, e.g. 2022-11-26T09:00:00Z[Australia/Melbourne]
>
>
> I hate it - it's very human-unfriendly.  Either the Z means something
> different here (ick) or you just specified a time 11 hours after the time I
> specified in my example.
>
> 2. Keep local time fixed by omitting the offset from the string, e.g.
> 2022-11-26T20:00:00[Australia/Melbourne]
>
>
> Oh - you specified all of them 11 hours later.  My examples were all 9am
> in my time, but you've gone for 8pm in my time.
>
> This looks great except for one knotty problem - it's not an RFC3339
> production.  Which is why my proposal, which keeps the RFC3339, and it very
> clear.
>
> 3. Send both local time and offset, and leave it up to the receiver to
> decide what to do, e.g. 2022-11-26T20:00:00+11:00[Australia/Melbourne]
>
>
> This is the one that I specified as "offset wins".  There was a fair bit
> of interest, in the working group, in having the behaviour always well
> specified and not having "implementation defined" be a choice.
>
> What do folks think about those three syntaxes?
>
> For case (2), I'm not sure why we'd need a separate [tz=] syntax for this
> case, but maybe I'm missing something?
>
>
> Not if you're allowed to trim the offset away from an RFC3339 date, no.
> The 'tz' was there as a signifier of "the creator wants you to recalculate
> the offset before use.
>
> 2022-11-26T09:00:00Z[tz=floating]
>
>
> I admit I don't fully understand the use case for this syntax. If you know
> the instant but not the time zone, then why isn't  2022-11-26T09:00:00Z sufficient?
> If you know the local time but not the instant, then why isn't
> 2022-11-26T09:00:00 sufficient? If the only point of [tz=floating] is to
> notify the receiver that you don't know the time zone, then why not just
> omit the time zone annotation completely?
>
>
> There are two reasons to use this over 2022-11-26T09:00:00
>
> 1) so we keep the RFC3339 part intact.  I'm harping on about this because
> it's the entire point of my proposal.  Without that, the tz stuff is
> overkill.
> 2) it allows hinting of zone.  Hinting is optional of course, you could
> always use Z plus floating.  I don't know if explaining it out loud will
> help here.  I'll do up some nice slides anyway to see if I can make it
> clear.
>
> (speaking of which - during the session I'll need to take my chair hat off
> to do this, so I'm glad I have Mark there to help)
>
> It strikes me then that the fundamental problem here is that the goal is
> really to create a standardised serialisation of some date formats *that
> are not datestamps*, that are commonly used across applications on the
> web. It should use the same elements of syntax as RFC3339 but it's not
> exactly an "extension". All the problems seem to stem from trying to
> enforce that they can also be treated as single points in time.
>
>
> Yep, I'm inclined to agree with Neil here. When sending a partial zoned
> timestamp (e.g. I don't know the offset, or I know the timezone), I think
> the most obvious way to express "I don't know X" is to omit "X" from the
> string. I'm not sure it's a good idea to create a new syntax that pretends
> that it's an RFC3339-compliant timestamp when it's really not.
>
> when this was proposed at the last IETF, there was fairly strong pushback
> to the idea of the first part not being exactly an RFC3339 production - so
> I'm proposing a format which always contains an RFC3339 component and yet
> is reliably convertable.
>
>
> Do we know why there was such strong pushback?  What were the underlying
> concerns?
>
> I don't know the people involved so can't be sure, but I'd guess that
> adhering to RFC3339 syntax but not actually providing a meaningful
> timestamp would generate *more* pushback. But that's just a guess.
>
>
> I guess we'll see :)  I'm not really attached to my idea or anything, but
> it's the proposal that was bouncing around in my head to satisfy the
> requirement for an RFC3339 basis.
>
> Cheers,
>
> Bron.
> --
>   Bron Gondwana, CEO, Fastmail Pty Ltd
>   [e-mail]
>
>
> --
> Sedate mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/sedate
>