Max Nikulin <maniku...@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>
