[Top][All Lists]

[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: Wed, 12 Aug 2020 15:08:18 +0200

Attached is an updated ZIP containing the respun patch and the
unmodified samples. The patch is against
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

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.

Attachment: icalendar-patch+testcases_20200812.zip
Description: Zip archive

reply via email to

[Prev in Thread] Current Thread [Next in Thread]