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

[Ihor Radchenko]

Max Nikulin <manikulin@gmail.com> 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.

Instead, we can simply allow
https://www.gnu.org/software/libc/manual/html_node/TZ-Variable.html
formats. All of them are supported by `encode-time' anyway.

At least, in theory.
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"))

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

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

I am probably missing something though.

>> <2023-01-14 Sat 18:22+0800>
>> <2023-01-14 Sat 18:22+08>
>> <2023-01-14 Sat 18:22@+0800>
>> <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.

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
2. ISO 8601 format https://en.wikipedia.org/wiki/ISO_8601#Time_zone_designators

Of course, individual variants of time zone specs may be ambiguous
depending on the purpose. Users are to choose what they prefer

>> <2023-01-14 Sat 18:22@+08 +1w -5d>
>
> May be not suitable for time zones with DST since offset changes due to 
> time transitions.
>
> I am afraid, sometimes rather long (maybe even redundant) specification 
> is required, so overlays becomes must have (as for links) to keep 
> readability.

Not necessarily. Most of the timestamps can do just fine specifying
either explicit offset or a time zone name:

<2023-01-14 Sat 18:22@Asia/Singapore>
<2023-01-14 Sat 18:22+08>

More exotic scenarios will not be common.

And, if the users wish, we do have `org-time-stamp-custom-formats'.

-- 
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>