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

[thunk2@arcor.de (Thomas Plass)]

[-- Attachment #1: message body text --]
[-- Type: text/plain, Size: 5275 bytes --]

[specific Emacs behaviour/bug question at end, list subscribers please read on]

Ulf Jasper wrote at 18:17 on February 15, 2019:
: the patch looks good so far.  Could you please provide some testcases

thanks.  A set of iCalendar files is in the attached archive
along with a README and a slightly cleaner version of the patch.
However, for unit testing, you'd need to not only consider the
data but the OS, too.  What follows is not only meant as a reply
to your request but is also a question for the Emacs maintainers.

The date-time that prompted me to look at this in detail is Sat,
Nov 3 2018 20:15 Europe/Berlin local time, the OS is Windows (7).
I made tests with two pre-built binaries, the official GNU 26.1:

(emacs-version)
"GNU Emacs 26.1 (build 1, x86_64-w64-mingw32)
 of 2018-05-30"

and an older "SourceForge" 25.3 build.

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"))
  ;; force Windows behaviour, usually no TZ set 
  (setenv "TZ")                   
  (print (decode-time (encode-time 0 15 20 3 11 2018                            )))
  (print (decode-time (encode-time 0 15 20 3 11 2018 Europe/Berlin)              ))
  (print (decode-time (encode-time 0 15 20 3 11 2018 Europe/Berlin) Europe/Berlin))
  ;; force Unixoid/POSIX? behaviour
  (setenv "TZ" Europe/Berlin)
  (print (decode-time (encode-time 0 15 20 3 11 2018                            )))
  (print (decode-time (encode-time 0 15 20 3 11 2018 Europe/Berlin)              ))
  (print (decode-time (encode-time 0 15 20 3 11 2018 Europe/Berlin) Europe/Berlin))
  nil)


Official Windows-26.1 evals to (comments by me):

(0 15 20 3 11 2018 6 nil 3600)          ; correct, no-brainer

(0 15 19 3 11 2018 6 nil 3600)          ; wrong: 19:15?!

(0 15 20 3 11 2018 6 t 7200)            ; "less" wrong: DST is on?!

(0 15 20 3 11 2018 6 t 7200)            ; "less" wrong: DST is on?!

(0 15 20 3 11 2018 6 t 7200)            ; "less" wrong: DST is on?!

(0 15 20 3 11 2018 6 t 7200)            ; "less" wrong: DST is on?!


SourceForge 25.3 performs slightly better:

(0 15 20 3 11 2018 6 nil 3600)          ; correct

(0 15 19 3 11 2018 6 nil 3600)          ; wrong: 19:15?!

(0 15 20 3 11 2018 6 t 7200)            ; "less" wrong: DST is on?!

(0 15 20 3 11 2018 6 nil 3600)          ; correct

(0 15 20 3 11 2018 6 nil 3600)          ; correct

(0 15 20 3 11 2018 6 nil 3600)          ; correct


Never mind the DST weirdness, I can live with this behaviour as
producing the desired 20:15 is possible in a predictable fashion.

But it get's even weirder.

Consider the following different-zone conversion.
America/Creston is UTC-7, adding UTC+1 for Europe/Berlin makes an
8 hour difference.  So, Berlin 20:15 is Creston 12:15, see also
https://www.timeanddate.com/worldclock/converter.html?iso=20181103T191500&p1=37&p2=2274

Let's check:

(let ((Europe/Berlin "STD-01:00DST-02:00,M3.5.0/02:00:00,M10.5.0/03:00:00")
      (America/Creston "STD+07:00"))
  ;; force Windows behaviour
  (setenv "TZ")                   
  (print (decode-time (encode-time 0 15 12 3 11 2018)))
  (print (decode-time (encode-time 0 15 12 3 11 2018 America/Creston)))
  (print (decode-time (encode-time 0 15 12 3 11 2018 America/Creston) Europe/Berlin))
  ;; force Unixoid/POSIX? behaviour
  (setenv "TZ" Europe/Berlin)
  (print (decode-time (encode-time 0 15 12 3 11 2018)))
  (print (decode-time (encode-time 0 15 12 3 11 2018 America/Creston)))
  (print (decode-time (encode-time 0 15 12 3 11 2018 America/Creston) Europe/Berlin))
  nil)


Eval says (Official Windows-26.1):

(0 15 12 3 11 2018 6 nil 3600)  ; correct (no conversion possible)

(0 15 20 3 11 2018 6 nil 3600)  ; correct 20:15 with "their-zone" conversion only

(0 15 21 3 11 2018 6 t 7200)    ; wrong: 21:15 with "their zone" + "my zone" conversion 

(0 15 12 3 11 2018 6 nil 3600)  ; correct (TZ in env applicable for decoding only)

(0 15 21 3 11 2018 6 t 7200)    ; wrong time 21:15 + wrong DST=on

(0 15 21 3 11 2018 6 t 7200)    ; wrong time 21:15 + wrong DST=on


SourceForge 25.3 is slightly different:

(0 15 12 3 11 2018 6 t 7200)

(0 15 20 3 11 2018 6 nil 3600)

(0 15 21 3 11 2018 6 t 7200)

(0 15 12 3 11 2018 6 nil 3600)

(0 15 21 3 11 2018 6 t 7200)

(0 15 21 3 11 2018 6 t 7200)


Things are fine again for dates following (Nov 4 etc.), ie.
when October's "fifth week" comes to an end.

If I remember correctly, Arch Linux pre-built 26.1 is always correct.

So, getting the desired 20:15 is dependent on - what?  Is it possible
to drive decode-time/encode-time to always convert between time zones
correctly and if so, how?  Is this a bug in Emacs or am I just
uninformed?

Thomas


[-- Attachment #2: icalendar019-patch+testcases.zip --]
[-- Type: application/zip, Size: 6169 bytes --]