Re: Two problems with export to Google calendar

[Max Nikulin]

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.