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

[Shane Carr <[e-mail]>]

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?

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]


On Mon, Nov 8, 2021 at 4:02 AM Ujjwal Sharma <[e-mail]> wrote:

> Hello everyone!
>
> First of all, thanks Bron for kicking some energy into this discussion.
>
> On 08/11/2021 16.08, Justin Grant wrote:
> > 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):
>
> I apologize for some of the initial misunderstanding in this thread,
> since it seems that I didn't manage to convey the updates from the
> previous IETF meetings to the Temporal champions very well and Justin
> seems to be a little out of the loop.
>
> We received pushback in the past against allowing "timestamps" that are
> subsets of the RFC3339 format, which is why Bron made this proposal,
> which tries to reach a good middle-ground (it perfectly represents a
> floating time without relying on the non-standard format which omits the
> offset).
>
> Now, as you mentioned, this is of course not ideal, since omitting the
> offset is simpler, though it comes at the cost of relying on a
> non-standard (atleast as of yet) representation. While I'm not opposed
> to standardizing this format, there are a number of folks who have their
> doubts regarding this subject, and therefore we decided to keep it
> off-limits for the time-being.
>
> There's some ways we could try to standardize the subsets you mention
> without upsetting others, but IIUC that work is currently not in the
> scope of SEDATE as per the current charter.
>
> One way I could imagine this being done would be to have a second RFC
> that reifies some of these subsets of the full 3339 format (eg:
> "floating date", "floating time", "floating datetime") and then we could
> change the current extension RFC to allow extending any of these formats
> in addition to the full 3339 format. The former could be a simple RFC,
> containing just the ABNF grammar for the supported formats as well as
> some motivating use-cases perhaps.
>
> What do folks think? Would the RFC be within the scope of CALEXT
> instead? I'd believe so since a majority of the formats would have the
> strongest use-cases within the calendaring space.
>
> Ujjwal
>
> --
> Ujjwal "Ryzokuken" Sharma (he/him)
>
> Compilers Hacker, Node.js Core Collaborator and Speaker
>
> --
> Sedate mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/sedate
>