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

[Thomas Plass]

Attached is an updated ZIP containing the respun patch and the
unmodified samples. The patch is against
https://git.savannah.gnu.org/cgit/emacs.git/tree/lisp/calendar/icalendar.el
blob: d76c11050312b4a04ac1cbda436b3c08fc6f2cc5

Hopefully, this is OK as it is.

I also extended the README in the ZIP to clarify what the patch is about:

  The aim of the patch is to support robust date-time conversions based
  on the VTIMEZONE sections in the iCalendar data.  VTIMEZONE specifies
  the source timezone while the target timezone is supplied externally
  (by the OS, environment, user, etc).
  
  Assuming a target timezone of Europe/Berlin, the local start time of
  all events defined in the sample files is November 3, 2018 20:15h
  (20181103T201500).

Aside: the clerical (?) error in `icalendar--decode-isoduration' is
also part of the patch but has nothing to do with conversions.

Ulf Jasper wrote at 17:14 on August 11, 2020:
: Am 11.08.2020 um 13:01 (+0200) schrieb Lars Ingebrigtsen:
: 
: Thomas, could you please provide the expected results for the test files,
: one for each ics file?  Thanks!

Well, the expected result depends on:

 - The local timezone of the person running the code.  Where I'm
   sitting, it is November 3, 2018 20:15h for all samples.  

   Europe_Berlin-20181103T201500_no_in-calendar_VTIMEZONE.ics contains
   no VTIMEZONE and thus has a somewhat undefined result.  The user
   agent is assumed to do the right thing based on OS/environment/user/AI.

   Note: this particular date+time is carefully chosen as it is
         subject to DST adjustments.  Under MS-Windows, it exercises
         Emacs' buggy DST handling.  But this fact is just incidental
         and not addressed by the patch.

 - Expectations as to how the conversion result is to be rendered.  In
   my case rendering of the iCal data is done by a MIME handler I
   cooked up for VM.  This is mainly used for rendering incoming
   meeting requests necessitating accurate date calculations.

Technical note: The concept of "target zone" is implemented by an
additional optional argument to `icalendar--decode-isodatetime'.  My
VM plugin's function for getting the event dates (inspired by
`icalendar--convert-ical-to-diary') says:

  (icalendar--decode-isodatetime dtstart nil dtstart-zone local-zone)

where there is a lot of apparatus for computing 'dtstart-zone and
'local-zone.  If you'd like to know more, I can send the code.

icalendar-patch+testcases_20200812.zip
Description: Zip archive