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

[Bron Gondwana <[e-mail]>]

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]