Christian Moe <m...@christianmoe.com> writes: > From this perspective I'd be happier with the less concise, but super > explicit > > 2022-11-12 14:00 UTC+2 > 2022-11-12 14:00 UTC-2:30
[2022-11-12 14:00 @UTC+2] [2022-11-12 14:00 @UTC-2:30] are also fine within the proposed format. Note, however, that because we are conforming to POSIX TZ, @UTC+2 is two hours _behind_ the Greenwich. https://www.di-mgt.com.au/wclock/help/wclo_tzexplain.html: Explanation of TZ strings General format of an entry in the file wclocktz.ini: [continent/city] TZ=posix-tz-string Time zones that do not have daylight savings have a simple TZ string, e.g. [Pacific/Honolulu] TZ=HST10 Where HST is the designation for the time zone (in this case Hawaii Standard Time) and 10 is the offset in hours. The offset indicates the value one must add to the local time to arrive at Coordinated Universal Time (UTC, aka GMT), and so it is positive for west of the meridian, e.g. America, and negative for east, e.g. China. [Asia/Beijing] TZ=CST-8 Minutes and seconds are optional, so CST-8 and CST-08:00:00 mean the same thing. Note that the sign convention (+/-) used in a Posix TZ string is the opposite to that used in Internet time offsets (RFC 3339) and in Arthur David Olson's TZ data files. -- 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>