bug#34315: [PATCH] icalendar.el: DURATION fix + more robust timezone handling

[Eli Zaretskii]

> Date: Mon, 18 Feb 2019 10:36:29 +0100
> From: thunk2@arcor.de (Thomas Plass)
> Cc: 34315@debbugs.gnu.org
> 
> I don't know what makes Sat, Nov 3 2018 (and the weekdays preceding
> it) so peculiar, but my hunch is its proximity to the DST transition
> that occured on the Sunday six days earlier, the "fifth week" of Oct.
> 
> The decode/encode combo in the forms below is essentially the
> guts of icalendar--decode-isodatetime(), old and patched.  The
> zone rule for Europe/Berlin is the current standard one, also
> computed by icalendar--convert-tz-offset().
> 
> The point of these examples is to see how time zone rules
> missing/supplied/in environment affect date-time conversions.
> 
> Here's code for a same-zone scenario, note the two TZ setenv()s:
> 
> (let ((Europe/Berlin "STD-01:00DST-02:00,M3.5.0/02:00:00,M10.5.0/03:00:00"))

You cannot expect MS-Windows to support Posix DST rules such as above
in the C runtime functions like mktime, localtime, etc.  Windows
support for DST rules in C runtime is very rudimentary, and is limited
to the likes of EST-5DST, without any specification of when the DST
transitions happen (the transition dates are hard-coded in the Windows
C runtime).

I think this factoid goes a long way towards explaining why you get
wrong results for the timezone offset around the DST transition date.

To make myself clear: modern Windows systems do have database of DST
transition rules, and they do apply these rules both for setting the
system clock and in APIs such as GetTimeZoneInformation.  But the
rules are not in Posix format (although the information is of course
equivalent), and these capabilities are not propagated to C runtime
functions which Emacs uses.