emacs-orgmode
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Max Nikulin
Subject: Re: [FEATURE REQUEST] Timezone support in org-mode datestamps and org-agenda
Date: Mon, 16 Jan 2023 23:43:58 +0700
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.4.2

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.





reply via email to

[Prev in Thread] Current Thread [Next in Thread]