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

[Ujjwal Sharma <[e-mail]>]

CCing Temporal champions mailing list for greater visibility

On Sun, Nov 7 2021 at 14:16:13 +1100, Bron Gondwana 
<[e-mail]> wrote:
> 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]
> 
>