Re: [FEATURE REQUEST] Timezone support in org-mode datestamps and org-agenda

[Ihor Radchenko]

Tim Cross <theophilusx@gmail.com> writes:

> If the timestamp only contains the abbreviated name e.g. AEST, then
> there is no automatic way to disambiguate - best we could
> do is issue a warning. The abbreviated TZ name, unlike the full TZ name,
> is really just a shorthand for the time offset from UTC at a specific
> point in time. The full TZ name on the other hand states not only the
> UTC offset, but also the TZ rules (and with things like the IANA TZ
> database, the specific TZ rules in place at the point in time that
> timestamp represents). This is essentially Max's main point - if
> timestamps for the future have the full TZ name, then we can manage
> things like changes in TZ database rules which occur after creation of
> the timestamp or adjusting timestamps (for scheduled tasks) based on
> changes in location etc). This would not be possible with abbreviated TZ
> or just UTC offsets.

Sure. That's what I proposed by

<2023-01-16 Mon 12:00@Australia/Melbourne>

But we may as well allow UTC offsets there

<2023-01-16 Mon 12:00+0200>

whichever users prefer to use in their use case.

Both the variants may be preferred depending on the purpose. The first
is good when we need to conform to local time, including all the
possible changes in TZ rules. The second is good when we, say, want to
schedule something "102000 _actual_ hours from the beginning of the
experiment; don't care about what government may decide about
winter/summer time in future"

> So I guess the timestamp format and the code which manages them will
> need the ability to use the full TZ name and not just the abbreviated
> form (and I guess an option to allow the user to select). In fact, we
> probably need a way to select between abbreviated/full dynamically as
> well as you might use the different TZ types as a way to flag which
> timestamps you want to adjust due to TZ changes (either in TZ db or in
> user location) and those you don't want changed.

Sure. We should get it for free because both GMT+8 and Asia/Singapore
are the valid TZ values. Both supported by Emacs' `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>