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: 2051 bytes --]

The attached patch contains a fix for what looks like a clerical error
in icalendar--decode-isoduration(), test case: P1DT2H.

But the real point of this post is to propose a few improvements to
handling timezones.

I use icalendar.el as a library for dealing with raw VCALENDAR data.
Also, I'm on Windows where the OS makes Emacs' timezone handling a
bit tricky.  Meaning that, unless precautions are taken, datetime
conversions by icalendar.el sometimes are incorrect, in particular
around DST transitions.

Changes in the patch:

 - add an optional argument to icalendar--decode-isodatetime() which
   is passed to decode-time().

   So, both encode-time() and decode-time() get to have their
   respective timezones which makes datetime conversions predictable.
   I know, I could do a (setenv "TZ" (icalendar--convert-tz-offset
   ...))  before I call icalendar--decode-isodatetime() but that +
   restoring the environment variable afterwards looks clumsy.

 - handle RDATE in icalendar--convert-tz-offset() in a rudimentary
   fashion.

   RDATE handling is required for those VTIMEZONEs that do not specify
   RRULE, otherwise there will be no datetime conversions at all.

 - identify the latest oberservance for DAYLIGHT and STANDARD
   specifications within one VTIMEZONE, again supporting RDATE.

   As is, icalendar.el handles multiple such specifications
   indiscriminately, resulting in conversions that may be relative to
   a date centuries in the past.

   The relevance of this change is this: when a VCALENDAR does not
   contain a VTIMEZONE section or e.g. the popular nonstandard
   X-WR-TIMEZONE property, my application goes and fetches one from a
   tzdata database such as tzurl.org.  Standard tzurl.org responses
   contain lots of historical records.  Yes, tzurl.org also returns
   "Outlook-style" VTIMEZONEs which icalendar.el is quite happy with
   but that doesn't help me with complex VTIMEZONEs contained in
   incoming VCALENDARs.


The patch is not a --git diff.  Is that tolerable at all?

Best regards

Thomas



[-- Attachment #2: icalendar.el.patch --]
[-- Type: application/x-diff, Size: 5712 bytes --]