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

[Carsten Bormann <[e-mail]>]

On 8. Nov 2021, at 08:40, Justin Grant <[e-mail]> wrote:
> 
>  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.

This.

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

There was (and still is, at least in my mind) confusion on how much SEDATE thingies (we need a name for them) are 
(1) RFC 3339 extended
(2) almost, but not entirely unlike RFC 3339.

RFC 3339 is for 
(a) UTC-referenced timestamps, possibly annotated with a UTC offset.
This annotation could be extended by SEDATE to provide an annotation what timezone that UTC offset stands for.
But this is additional information; the meaning otherwise doesn’t change.

The pushback was about leaving the territory of (a), because some people wanted SEDATE to be (a) only.

Some proposals/use cases here

(b) are almost timestamps, but reference a timezone with the intent to update the actual time stamp based on changes to the timezone;
(c) are not timestamps at all, but user-visible indications of intent that only make sense in the context of a specific user (“floating”).

(b) is still mostly deterministic (i.e., there are usually ways to find out how a timezone changes, so after a little period of confusion people again agree what timestamp is/was meant).

(c) is maybe a form of calendaring, but surely not a timestamp, because its interpretation changes by who looks at it.
It should most definitely not look like RFC 3339 (e.g., by leaving out offset info).

By the way, the military character for “local time” is “J" (where “Z” is world time), so the natural way to say

2022-11-26T09:00:00🤦‍♂️[tz=floating]

is

2022-11-26T09:00:00J

Not RFC 3339, and clearly saying that this is not a timestamp unless context is added.

Grüße, Carsten