Timothy <orgm...@tec.tecosaur.net> writes: > This functions well, however I see a potential to be confusing at a glance > here. > Consider the visual similarity of 10:30 to 11:00 in local time and 10:30 in > UTC-11, and the combination of both. > > ┌──── > │ [2022-11-12 10:30-11:00] > │ [2022-11-12 10:30-1100] > │ [2022-11-12 10:30-11:00-1100] > └────
Note that an alternative is [2022-11-12 10:30-11:00] [2022-11-12 10:30-11] [2022-11-12 10:30-11:00-11] which is much less confusing. > I’d be inclined to put the UTC offset together with the time zone name if > possible. Do you think something along the lines of `@-1100,America/Anchorage' > could be viable? I’d think that would reduce the chance of confusion. > > ┌──── > │ [2022-11-12 10:30-11:00] > │ [2022-11-12 10:30 @-1100] > │ [2022-11-12 10:30-11:00 @-1100] > └──── This might be an option. A slight disadvantage is more verbose syntax for simple timestamps like [2022-11-12 10:30+02] [2022-11-12 10:30 @+02] >> 2022-11-12 12:00+07 @!Asia/Singapore >> >> Org will calculate the internal time for both +07 offset and >> Asia/Singapore time zone. If they do not match, Org will issue a >> warning. The offset will still be preferred if we have to proceed. >> >> This can be useful when planning future meetings and sending Org file >> with a timestamp to someone else, potentially with obsolete tzdb. > > I like the way that combining these features works, but I do wonder if perhaps > warning when these two bits of information don’t match should be the default > behaviour, and the `!' used to specify which of them should be prioritised? I am not sure if it is a good idea. > It also occurs to me that this proposed behaviour might be easier with a > single > `@TZINFO' form as I mentioned earlier, e.g. > > ┌──── > │ [2022-11-12 12:00 @+07,Asia/Singapore] # warn when mismatch > │ [2022-11-12 12:00 @+07,!Asia/Singapore] # use Asia/Singapore over +07 Consider the requests about time zone abbreviations. Without "always warn", we can do [2022-11-12 12:00 @+08,CST] with CST being ambiguous (and also not supported by `encode-time'). -- Ihor Radchenko // yantar92, Org mode contributor, Learn more about Org mode at <https://orgmode.org/>. Support Org development at <https://liberapay.com/org-mode>, or support my work at <https://liberapay.com/yantar92>