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

[Justin Grant <[e-mail]>]

>
> 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]


For cases where the offset is known, but the sender wishes to communicate
their intent to prefer either offset or IANA name, then another extension
seems like a reasonable possibility to bikeshed. (Although it does break
backwards-compatibilty with RFC 3339 so I suspect it may get pushback from
folks who care more about backwards compat.)

But I think a more fundamental issue is that, at least as I undertsand it,
floating times as specified in RFC 5545 3.3.5
<https://datatracker.ietf.org/doc/html/rfc5545#section-3.3.5> are not
stored with an offset at all. The original offset is unknown.

      To properly communicate a
      fixed time in a property value, either UTC time or local time with
      time zone reference MUST be specified.


This is why I assumed that a subset was the only appropriate way to
serialize that offset-less data model, because one of the required
components was missing.

Cheers,
Justin



On Mon, Nov 8, 2021 at 8:13 AM Shane Carr <sffc=[e-mail]>
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?
>
> 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
>>
> --
> Sedate mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/sedate
>