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

[Tim Cross]

Ihor Radchenko <yantar92@posteo.net> writes:

> Tim Cross <theophilusx@gmail.com> writes:
>
>> 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.  
>
> So, basically we may need a way to (1) identify ambiguous TZ
> specifications; (2) signal to user about potential issues.
>
> Note that these are also optional features we may implement any time
> once we have basic timezone support.
>
> For (2) we may use something similar to `world-clock' - display user
> timestamp at point for different time zones. Maybe via eldoc.


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.

As an example, I'm in Australia/Brisbane TZ and I create a timestamp. If
it only has the AEST TZ info, when I travel to Australia/Melbourne org
would not be able to identify I'm in a TZ with an offset of +1100 rather
than +1000 because both use AEST (for NSW it likely would work as NSW
uses AEDT during daylight savings time). However, if the TZ was full
name i.e. Australian/Brisbane, then it does know and can adjust because
my local TZ has changed to Australia/Melbourne. 

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.

I also note a comment from an earlier thread regarding timestamps and
historical changes in tz info. I don't think this is an issue.  As far
as I know, past TZ rules/information rarely, if ever, change. It is only
with respect to future dates it is a problem and I doubt there is much
that can be done. For example Postgres recognises that a future
timestamp may become incorrect due to changes in TZ rules post creation
of the timestamp, but they specifically state they don't handle that
situation and that their model has an implicit assumption that the TZ
rules associated with a TZ don't change. In other words, from their
perspectrive, you would have to have a different process which monitors
TZ database information and when it changes, examine your db of
timestamps for ones which have been affected and adjust accordingly
(assuming it matters enough of course). I think org could eventually
reach a middle ground - if a future timestamp has the full tz name, then
changes can be applied, but if not they cannot and leave it to the user
to decide which is used.