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

[Tim Cross <theophilusx@gmail.com>]

Max Nikulin <manikulin@gmail.com> writes:

> On 14/01/2023 20:08, Jean Louis wrote:
>> * Max Nikulin [2023-01-14 10:14]:
>>> Let's assume <2023-01-15 Sun 09:00 +1>
>>>
>>> It may be suitable for timestamps in the past, but future is more tricky.
>>> There is no problem if you are going to watch Lunar eclipse. However if your
>>> plan is to attend a local event there is a chance that you will arrive at
>>> wrong time. Sometimes offset of timezones is changed and it may happen
>>> between the moment when you added a scheduled time and the moment of the
>>> event.
>> Can't follow you.
>> with "+1" I would say it is time zone.
>> Basic point is that users shall learn to express themselves by using
>> time zone.
>
> "+1" is not a timezone, it is current offset shared by several timezones. You can not
> assure that time offset at a particular location would not change due to new
> administrative rules.
>
> E.g. Europe/Berlin is a timezone, but, strictly speaking, is still
> underspecified. Sometimes timezones are split into smaller parts.

Yes, this is a problem. We really want a symbolic TZ
specification and we would need 'smarts' i the timestamp generation code
that is able to handle potential offset changes due to daylight savings
transition etc. Even then, the transition time can change between when
the timestamp is set for and when it actually occurs.

Unfortunately, the common abbreviated forms like EST, AEST etc are
inconsistent here. Some places will have a standard and a daylight
savings type i.e. AEST and AEDT, while others will have just AEST. TO
make it worse, two locations with the same time zone offset my use
different versions i.e. Australia/Melbourn is AEST (+10/+11) and
Australia/Sydney is AEST (+10) and AEDT (+11) and Australia/Brisbane is
just AEST (+10). If everywhere which has daylight savings ensured they
used a different abbreviation for daylight saving and non-daylight
saving times, life would be easier, but they don't). Then of course
there are many countries which don't have a symbolic letter abbreviation
i.e. just have e.g -05 as their abbreviated TZ name.

It is this and other related reasons why just relying on Emacs' internal
API for times and dates is not sufficient. The abbreviated times have
ambiguity and the full timezone specification is cumbersome and
ugly. Even worse is that issue won't be shown up as failures - you will
just silently get wrong results.  

If on the other hand all the timestamps were in UTC, you avoid lots of
these issues. However, you would then also require a 'view'
layer/overlay which would take the UTC time, apply whatever the local TZ
is and show that result as the timestamp. THis would avoid things being
out by an hour due to daylight savings transitions and would mean the
user would see timestamps relative to whatever their local time zone is,
regardless of changes in location which has also changed time zones.

The problem with this approach is that now you have lost the 'plain
text' nature of org files. When editing the value, the user would need
to remember the value stored in their org file is UTC, not local
time. Many exporters would also need to be updated to handle conversion
to local time as well.