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

[[e-mail]]

Carsten Bormann <[e-mail]> wrote:

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

This is an interesting way to put it, and one I hadn't fully considered 
before. RFC 3339 specifies a syntax intended to express a particular semantic:
That of a fixed point in time, aka a timestamp. In previous discussions there
has been a lot of concern about extending the syntax for timestamps.

But if what's being represented is not, in fact, a particular point in time,
would it not in fact be better to use a syntax that's intentionally
incompatible?

This isn't a simple question with an obvious answer. Full syntax compatibility
does have some value, after all. And beyond that, the trick of dropping the
time offset only works if lack of zone specificity is the only reason why the
value can't be treated as a timestamp. If there are going to be other reasons
why one of these values doesn't specify a point in time it significantly
diminishes the value of the approach.

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

The original pushback was against specifying something with the intention, of
obsoleting RFC 3339 with an extended syntax. (The original proposal was, in
fact, a direct revision of RFC 3339.)

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

Agreed.

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

FWIW, my pushback was almost exactly the opposite of this: I never had a 
problem with work on timey-wimey non-timestamp things. My concern was with
possible impact on existing use of the timestamp format.

> 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”).

But do they always float in the sense of the zone being the thing that's not
nailed down? 

And there's also (d):

(d) A timestamp annotated with information about how best to display it, e.g.,
    using an alternate calendar.

> (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).

Agreed.

> (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).

OK... so if we accept this reasoning, there needs to be an explanation of
why the samething doesn't apply to the "almost timestamps" of (b).

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

FWIW I slightly prefer the J approach, but let's not dive into syntax details
until there's agreement on the more abstract points.

				Ned