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

[Ihor Radchenko]

Max Nikulin <manikulin@gmail.com> writes:

>> 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 think we could allow the "double zone" idea I mentioned in another
discussion branch:

<2023-10-29 Sun 3:00+0200@Europe/Berlin> -> (+1 minute)
<2023-10-29 Sun 2:01+0100@Europe/Berlin>

Because 2:01 will happen twice that day, it will also be possible to specify 

<2023-10-29 Sun 2:01+0200@Europe/Berlin>

I think it is more intuitive compared to DST/no DST.
And we do not even need to parse this scenario specially:

The variants of the TZ spec will be:

HH:MM@[^\n>\]]+
HH:MMZ
HH:MM[+-−][0-9]{2}\([0-9]{2}\)?
(note that I don't list times like 12:00+02:00 because it will interfere
with time range syntax 08:00-09:00 is a time range, but might also be
08:00-0900 time zone)

then, "@Europe/Berlin" in 2:01+0200@Europe/Berlin will be simply ignored
and we will use the explicit UTC offset.

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

I see. This is not the only pitfall though.

I just discussed the same issue with Tecosaur, and he noted
that <2023-10-29 2:59@Europe/Berlin> is ambiguous because 2:59 occurs
twice during that day:

  2:59 -> 3:00 (DST -1 hour transition) -> 2:01 -> ... -> 2:59 -> 3:00 -> 3:01

The fact that `encode-time' chose 2:59 after the transition is
implementation detail.

To deal with such cases, we may provide org-lint checker that will
compare timestamps with t and nil DST parameter for `encode-time' and
warn if there is a difference.

(encode-time '(0 59 2 29 10 2023 nil -1 ":Europe/Berlin")) ; => (25917 44628)
(encode-time '(0 59 2 29 10 2023 nil t ":Europe/Berlin")) ; => (25917 44!628) 
(same)
(encode-time '(0 59 2 29 10 2023 nil nil ":Europe/Berlin")) ; => (25917 
48!!228) (different)

(encode-time 0 59 2 29 10 2023 nil -1 ":Europe/Berlin") ; => (25917 48!!228)
(encode-time 0 59 2 29 10 2023 nil t ":Europe/Berlin") ; same
(encode-time 0 59 2 29 10 2023 nil nil ":Europe/Berlin") ; same

So, there is a gotcha with `encode-time' API, and we must use the list
argument. (This gotcha is described in the docstring, but in rather
cryptic way)

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

Sure. Having per-file/heading time zone settings will also help.

I don't think that people will mind _occasional_ timestamps having
Asia/Singapore. I'd personally prefer this kind of verbosity for
overseas remote events.

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

Let's just recommend +-XXXX and @location in the manual. And mention
briefly that TZ format is supported in addition.

We might also provide an optional linter for GMT, if necessary.

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

Could you please elaborate? I don't fully understand what you are
referring to.

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