[Sedate] A syntax proposal: floating and future times

[Bron Gondwana <[e-mail]>]

One of the biggest areas of debate in the meetings so far has been how to handle a mismatch between the zone and the offset, and whether to allow floating times.

I've had an idea in my head for a bit, so I figured I should write it out in advance of our meeting next week!

The basic principles are:
 * the special name 'floating' is used to specify that the timezone will be resolved at the point of display or use
 * the zone in brackets is advisory only, the offset always wins
 * the namespace 'tz' specifies a timezone which overrides the offset.  That means that a time with a 'tz' namespace may be different than timestamp defined purely by the RFC3339 part, thought it's recomended to use the best-guess at what the offset is likely to be in the timestamp, so that systems which don't understand this extension still give as good position as possible.

My example timepoint will be 9am on my birthday - not this year, but next year - giving enough time for some likely changes to happen.  So that's

`2022-11-26T09:00:00`

I expect that I'll probably be at home when I create this, so by default I would create one of these:

`2022-11-26T09:00:00+11:00`
`2022-11-26T09:00:00+11:00[Australia/Melbourne]`

These both mean `2022-11-25T22:00:00Z` and always will, no matter when they are resolved.

*Changes to zone offsets**
*

Let's suppose the the Victorian government decided to join with Queensland and stop doing daylight saving next year, so "Australia/Melbourne" would then resolve to +10 in late November.  I could use this syntax:

`2022-11-26T09:00:00+11:00[tz=Australia/Melbourne]`

Which would start out as `2022-11-25T22:00:00Z` still, but would change to `2022-11-25T23:00:00Z` once the local zone database was updated.

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

(I'm happy bikeshed alternative syntax, e.g. `[tz-floating=true]` - just a clear way to specify this concept.  An advantage of having 'tz=' for both is that the "closest bound wins" rule applies - and you don't get confusion if both floating and a named timezone are specified on the same item - the first one always wins)

So if I'm still in Melbourne for my birthday next year, then it's the same as one of the above examples, but if I went to IETF115 in Madrid (assuming we go there for November next year!) and wound up still in Europe for a few weeks after, then it might resolve to `2022-11-26T08:00:00Z` for me, because I'd only be one hour ahead of UTC.

*While we're at it, what about TAI?**
*

Maybe I care about the alignment of the heavens at exactly 9am on my birthday being exactly 31536000 seconds since 9am Melbourne time on my birthday this year!  Maybe I could write:

`2022-11-26T09:00:00+11:00[tz-tai=37]`

Where 'tz-tai=N' defines the integer TAI offset that was expected to apply at the time.

Then if a leap second gets added or removed at the end of this year, this could resolve to a UTC date of:

`2022-11-25T21:59:59Z` or `2022-11-25T22:00:01Z`

(either way, it's the same TAI date of `2022-11-25T21:59:23`, regardless of leapseconds)

Obviously - these could all be stacked and the rules would be very clear about what to do, though it would be pretty weird to care about the exact TAI offset but NOT the exact UTC offset.

...

I think this is all consistent and easily implementable.

In particular, it creates clarity around handling:
 * If you specify an unadorned timezone, then the timezone is advisory and the offset always wins.
 * If you specify anything with the 'tz' namespace, then the offset is advisory and the timezone information overrides at the point when the date is resolved.
 * If the timezone can't be resolved, then the offset can be used as a fallback - so implementations SHOULD use their best guess as to the offset that is likely to be meaningful (e.g. local timezone of the user or system that created the date)

Regards,

Bron.

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