[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#34315: [PATCH] icalendar.el: DURATION fix + more robust timezone han
From: |
Thomas Plass |
Subject: |
bug#34315: [PATCH] icalendar.el: DURATION fix + more robust timezone handling |
Date: |
Mon, 4 Feb 2019 12:48:11 +0100 |
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
icalendar.el.patch
Description: application/diff
- bug#34315: [PATCH] icalendar.el: DURATION fix + more robust timezone handling,
Thomas Plass <=
- bug#34315: [PATCH] icalendar.el: DURATION fix + more robust timezone handling, Ulf Jasper, 2019/02/12
- bug#34315: [PATCH] icalendar.el: DURATION fix + more robust timezone handling, Ulf Jasper, 2019/02/15
- bug#34315: [PATCH] icalendar.el: DURATION fix + more robust timezone handling, Thomas Plass, 2019/02/18
- bug#34315: [PATCH] icalendar.el: DURATION fix + more robust timezone handling, Eli Zaretskii, 2019/02/18
- bug#34315: [PATCH] icalendar.el: DURATION fix + more robust timezone handling, Thomas Plass, 2019/02/18
- bug#34315: [PATCH] icalendar.el: DURATION fix + more robust timezone handling, Eli Zaretskii, 2019/02/18
- bug#34315: [PATCH] icalendar.el: DURATION fix + more robust timezone handling, Thomas Plass, 2019/02/18
- bug#34315: [PATCH] icalendar.el: DURATION fix + more robust timezone handling, Eli Zaretskii, 2019/02/18