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

[Max Nikulin <manikulin@gmail.com>]

On 15/01/2023 20:41, Ihor Radchenko wrote:
> Max Nikulin writes:
>> On 14/01/2023 18:42, Ihor Radchenko wrote:
>>>
>>> <2023-01-14 Sat 18:22@Asia/Singapore>  (SGD and similar abbreviations are often ambiguous)
>>
>> Such format is ambiguous for timezones with DST around backward time
>> jump. Before/after time transition should be specified in addition, e.g.
>> by combining identifier and offset or some way to state namely before or
>> after.
> 
> Are you referring to one hour in year when the clock is moved one hour
> forward?
> 
> <2023-10-29 Sun 3:00@+DST/Europe/Berlin> -> (+1 minute)
> <2023-10-29 Sun 2:01@-DST/Europe/Berlin>
> 
> I, however, do not feel like we need this +/-DST special notation.
> Chances that one needs a timestamp in this specific hour are slim. At
> the end, countries deliberately choose the time transition to not
> interfere with business activity.

Yes, I do not mind to be able to represent 2023-10-29 Sun 2:01 before 
and after transition in the Europe/Berlin timezone. Notice that Python 
developers chose "fold" instead of "DST" for argument and field name:
https://peps.python.org/pep-0495/
PEP 495 – Local Time Disambiguation

We should have this in mind, but I agree the priority is not highest one.

> I just tried:
> 
> (time-subtract
> (encode-time 0 1 3 29 10 2023 nil -1 ":Europe/Berlin")
> (encode-time 0 59 2 29 10 2023 nil -1 ":Europe/Berlin"))

Pass list to `encode-time', not separate values in Emacs >= 27, since 
this case DST is -1 (guess) it is not important, but generally the value 
is ignored. It is a pitfall in API.

> (see https://www.timeanddate.com/time/zone/germany/berlin)

You can inspect your local database
     zdump -v Europe/Berlin

> and it looks like the expected return value should be 1 hour 2 minutes
> (3720), but it is not, on my system.

it is assumed that you should explicitly specify DST to get another 
branch (but at first you should determine somehow at which side DST 
should be applied):

(let* ((tz "Europe/Berlin")
        (t1 (encode-time `(0 1 3 29 10 2023 nil nil ,tz)))
        (t2 (encode-time `(0 59 2 29 10 2023 nil t ,tz))))
   (list
    (format-time-string "%F %T %z %Z" t1 tz)
    (format-time-string "%F %T %z %Z" t2 tz)
    (time-subtract t1 t2)))
("2023-10-29 03:01:00 +0100 CET" "2023-10-29 02:59:00 +0200 CEST" 3720)

Actually behavior is more funny, but I need more time to investigate it 
more close.

The real problem with libc is that TZ DB contains time transitions 
preserving DST value and DST argument of `encode-time' becomes useless:

Europe/Kyiv  Sat Jun 30 21:59:59 1990 UT = Sun Jul  1 01:59:59 1990 MSD 
isdst=1 gmtoff=14400
Europe/Kyiv  Sat Jun 30 22:00:00 1990 UT = Sun Jul  1 01:00:00 1990 EEST 
isdst=1 gmtoff=10800

zdump -v Africa/Juba
...
Africa/Juba  Sun Jan 31 20:59:59 2021 UT = Sun Jan 31 23:59:59 2021 EAT 
isdst=0 gmtoff=10800
Africa/Juba  Sun Jan 31 21:00:00 2021 UT = Sun Jan 31 23:00:00 2021 CAT 
isdst=0 gmtoff=7200

>>> <2023-01-14 Sat 18:22@+08>
>>
>> May become incorrect for future events due to updates of timezone database.
> 
> Emm. No? +8 is offset from UTC. It will not be affected by anything.
> Or are you referring to scenarios when user actually wants to specify the
> timestamp for specific country/city? Then the TZ variant should be used
> instead.

Certainly events are usually associated with some area. I think, users 
will prefer concise +0800 notation to full timezone ID like 
Asia/Singapore and will get unexpected results sometimes. Manual should 
stress that fixing time offset is not a bright idea for planning.

> What I am essentially proposing in these examples is allowing:
> 1. TZ format as described in https://www.gnu.org/software/libc/manual/html_node/TZ-Variable.html

Some formats may be confusing for users, e.g. TZ=GMT+5 actually means 
-0500 offset.

> 2. ISO 8601 format https://en.wikipedia.org/wiki/ISO_8601#Time_zone_designators

I do not see IANA identifiers here. Moreover currently there is no API 
to get list of IANA identifiers. On windows additional mapping may be 
required:
https://unicode-org.github.io/cldr-staging/charts/37/supplemental/zone_tzid.html

I do not mind to fix timestamps in past by adding offsets like +0100. 
For planning timezone identifiers should be strongly preferred unless 
time is really fixed in respect to UTC.