Two problems with export to Google calendar

Two problems with export to Google calendar

[Neil Jerram]

Firstly, when I last exported during late summer, org generated an
.ics file with

X-WR-TIMEZONE:BST

which I think was intended to mean British Summer Time; but Google
interpreted it as Bangladesh Standard Time.  As a result, my events
from Org are shown at the wrong time in Google calendar.

Secondly, it seems to me that the concept of having a timezone for the
whole .ics file might be wrong.  My Org files have dated events in
both the summer and the winter, and it is obvious to me that the times
for the summer events should be understood as British Summer time
(UTC+1), and that the times for the winter events should be understood
as GMT (UTC).

Do others agree with that?  If so, it would need to be reflected on
export by each event having its own timezone, instead of a global
timezone for the whole file.

Best wishes,
     Neil

Re: Two problems with export to Google calendar

[Neil Jerram]

On Wed, 7 Dec 2022 at 11:30, Neil Jerram <neiljerram@gmail.com> wrote:
>
> Firstly, when I last exported during late summer, org generated an
> .ics file with
>
> X-WR-TIMEZONE:BST
>
> which I think was intended to mean British Summer Time; but Google
> interpreted it as Bangladesh Standard Time.  As a result, my events
> from Org are shown at the wrong time in Google calendar.
>
> Secondly, it seems to me that the concept of having a timezone for the
> whole .ics file might be wrong.  My Org files have dated events in
> both the summer and the winter, and it is obvious to me that the times
> for the summer events should be understood as British Summer time
> (UTC+1), and that the times for the winter events should be understood
> as GMT (UTC).
>
> Do others agree with that?  If so, it would need to be reflected on
> export by each event having its own timezone, instead of a global
> timezone for the whole file.
>
> Best wishes,
>      Neil

Ah, it looks like the solution for both points might be customizing
org-icalendar-timezone as "Europe/London".  I will try that...

    Neil

Re: Two problems with export to Google calendar

[Ihor Radchenko]

Neil Jerram <neiljerram@gmail.com> writes:

> Firstly, when I last exported during late summer, org generated an
> .ics file with
>
> X-WR-TIMEZONE:BST
>
> which I think was intended to mean British Summer Time; but Google
> interpreted it as Bangladesh Standard Time.  As a result, my events
> from Org are shown at the wrong time in Google calendar.

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

> Secondly, it seems to me that the concept of having a timezone for the
> whole .ics file might be wrong.  My Org files have dated events in
> both the summer and the winter, and it is obvious to me that the times
> for the summer events should be understood as British Summer time
> (UTC+1), and that the times for the winter events should be understood
> as GMT (UTC).
>
> Do others agree with that?  If so, it would need to be reflected on
> export by each event having its own timezone, instead of a global
> timezone for the whole file.

You can set TIMEZONE heading property to provide a separate time zone
per entry. See 13.15 iCalendar Export section of the manual.

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

Re: Two problems with export to Google calendar

[Max Nikulin]

On 07/12/2022 19:56, Ihor Radchenko wrote:
> Neil Jerram:
> 
>> X-WR-TIMEZONE:BST
>>
>> which I think was intended to mean British Summer Time; but Google
>> interpreted it as Bangladesh Standard Time.  As a result, my events
>> from Org are shown at the wrong time in Google calendar.
> 
> 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

during generation of export template. There is a chance that init system 
is not systemd, so the command is not available. It is possible to get 
timezone from /etc/timezone, but the code would not concise since it may 
be a text file or a symlink to the definition. I have no idea concerning 
macOS or Windows.

Emacs relies on libc to handle time zones, and there is no API to get 
the identifier. I miss the option available in modern browser JavaScript

     new Intl.DateTimeFormat().resolvedOptions().timeZone

I have never read .ics file spec, so I am unaware what kinds of name are 
allowed for X-WR-TIMEZONE.

Re: Two problems with export to Google calendar

[Ihor Radchenko]

Max Nikulin <manikulin@gmail.com> 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
>
> during generation of export template. There is a chance that init system 
> is not systemd, so the command is not available. It is possible to get 
> timezone from /etc/timezone, but the code would not concise since it may 
> be a text file or a symlink to the definition. I have no idea concerning 
> macOS or Windows.

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

This is exactly what ox-icalendar does. If TZ is set, use it. Otherwise,
use `current-time-zone'.

> Emacs relies on libc to handle time zones, and there is no API to get 
> the identifier. I miss the option available in modern browser JavaScript
>
>      new Intl.DateTimeFormat().resolvedOptions().timeZone

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.

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

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.

Re: Two problems with export to Google calendar

[Ihor Radchenko]

Max Nikulin <manikulin@gmail.com> writes:

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

Thanks for the explanation.

I do not think that it is a problem Org has to solve. Rather Emacs. Or
even libc.

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