On 12/12/2022 21:00, Ihor Radchenko wrote:
Max Nikulin writes:

By default, ox-icalendar takes the value of your TZ environment variable.

I think, in most cases TZ is not set, so (format-time-string "%Z") is
used to get abbreviation (that is ambiguous).

On Linux we may try

      timedatectl show --property=Timezone --value

According to POSIX standard
(https://pubs.opengroup.org/onlinepubs/9699919799/), we need to use "TZ"
environment variable, when present. Otherwise, fallback to defaults.

I do not try to dispute such statement. The question is what should be taken as the default.

This is exactly what ox-icalendar does. If TZ is set, use it. Otherwise,
use `current-time-zone'.
...
The issue in this bug report is that TZ is actually set. Ambiguously. In
OS. We cannot do much about it. Outsmarting system settings is not a
good idea.

The TZ environment variable is not set and that is the issue. Otherwise the .ics file would have

X-WR-TIMEZONE:Europe/London

The problem is that there is no API to get time zone identifier in elisp because such function is missed in libc. It is possible to get only BST/GMT (depending on current season).

Identifiers like Europe/London allows to get history of time transitions. (format-time-string "%z %Z") and (current-time-zone) may only report time offset and ambiguous abbreviation at particular moment. Return values of these functions may vary for different timestamps in the calendar file. If list of time zones were available then it would be possible to iterate over it and to match particular time zone by abbreviation and offset for most of zones (perhaps some ambiguity would remain).

Actually `current-time-zone' is an example of fragile API for *current* time. Offset is valid for particular moment. There is no guarantee that offset would not change between obtaining it and applying to a timestamp. So the only safe way of using this function is with the SPECIFIED-TIME argument. In such case *current* in the function name is confusing.

So in my previous message I was considering feasibility of some platform-dependent code to determine time zone when neither TIMEZONE Org file property nor TZ environment are specified.


Reply via email to