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

[Justin Grant <[e-mail]>]

>
> *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]
2. Keep local time fixed by omitting the offset from the string, e.g.
2022-11-26T20:00:00[Australia/Melbourne]
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]

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?

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?

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.

Cheers,
Justin