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

[Bron Gondwana <[e-mail]>]

On Mon, Nov 8, 2021, at 15:11, Neil Jenkins wrote:
> On Sun, 7 Nov 2021, at 14:16, Bron Gondwana wrote:
>> *Floating time*
>> **
>> Suppose I just wanted to know when 9am was on my birthday, wherever I am in the world.  I would use something like:
>> 
>> `2022-11-26T09:00:00+11:00[tz=floating]`
> 
> This is not floating time. You've given it an offset: +11h. I don't understand this proposal at all. We already have a perfectly good syntax for a floating (a.k.a. wall-clock) date-time, in fact you used it earlier:
> 
> `2022-11-26T09:00:00`

Yes, but... the problem is that this is NOT an RFC3339 plus an extension, it's a subset of RFC3339.  So by putting the offset and the extension to say "adjust the offset to the current timezone", you get a treatment of floating which is basically "local time but we don't know the location/timezone yet".

Just like with the "localtime, zone overrides offset" version, there's still an offset hint.  This is different to ICALENDAR times, because this format currently always requires an exact timepoint in RFC3339 syntax, even if that timepoint might be adjusted if the offset no longer matches the zone once the zone is resolved.

> It's the one that everyone already intuitively uses for this. The only thing that's needed is to give it a name so it can be more easily referenced from other documents.

Ok... only, 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.  You can always do:

`2022-11-26T09:00:00Z[tz=floating]`

Which has identical meaning to the +11:00 example I gave above, except that if you don't know which zone to float into, it defaults to UTC - which is what at least Cyrus IMAPd does when it gets a floating time and has no timezone context (and the early bugs we had with alarms at the wrong time were precisely that - because there was no zone information in the alarm daemon until we figured out how to pass it down from the calendar default)

So you can reliably convert from this format into ICALENDAR's offsetless floating time, and reliably convert back by using 'Z' and [tz=floating].

Bron.

--
  Bron Gondwana, CEO, Fastmail Pty Ltd
  [e-mail]