unofficial mirror of bug-gnu-emacs@gnu.org 
 help / color / mirror / code / Atom feed
From: thunk2@arcor.de (Thomas Plass)
To: Ulf Jasper <ulf.jasper@web.de>
Cc: Lars Ingebrigtsen <larsi@gnus.org>,
	34315@debbugs.gnu.org, Thomas Plass <thunk2@arcor.de>
Subject: bug#34315: [PATCH] icalendar.el: DURATION fix + more robust timezone handling
Date: Wed, 12 Aug 2020 15:08:18 +0200	[thread overview]
Message-ID: <24371.59842.984273.402129@AGAME7.local> (raw)
In-Reply-To: Your message of Tuesday, August 11 2020 17:14:36 (ID: <87d03x43kz.fsf@panama>).

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

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.




[-- Attachment #2: icalendar-patch+testcases_20200812.zip --]
[-- Type: application/zip, Size: 6457 bytes --]

  parent reply	other threads:[~2020-08-12 13:08 UTC|newest]

Thread overview: 51+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-02-04 11:48 bug#34315: [PATCH] icalendar.el: DURATION fix + more robust timezone handling Thomas Plass
2019-02-12 18:57 ` Ulf Jasper
2019-02-15 17:17   ` Ulf Jasper
2019-02-18  9:36     ` Thomas Plass
2019-02-18 15:59       ` Eli Zaretskii
2019-02-18 19:15         ` Thomas Plass
2019-02-18 19:30           ` Eli Zaretskii
2019-02-18 20:03             ` Thomas Plass
2019-02-18 20:16               ` Eli Zaretskii
2020-08-10 11:48     ` Lars Ingebrigtsen
2020-08-10 16:08       ` Ulf Jasper
2020-08-10 16:45         ` Eli Zaretskii
2020-08-10 17:04           ` Thomas Plass
2020-08-11 11:01             ` Lars Ingebrigtsen
2020-08-11 15:14               ` Ulf Jasper
2020-08-11 15:19                 ` Lars Ingebrigtsen
2020-08-11 15:45                   ` Ulf Jasper
2020-08-12 13:08                 ` Thomas Plass [this message]
2020-08-12 13:12                   ` Lars Ingebrigtsen
2020-08-12 13:30                     ` Thomas Plass
2020-08-12 15:06                       ` Ulf Jasper
2020-09-02 18:05                         ` Ulf Jasper
2020-09-03  8:38                           ` Thomas Plass
2020-09-03 14:28                             ` Ulf Jasper
2020-09-12  8:01                               ` Thomas Plass
2020-09-12  8:11                                 ` Eli Zaretskii
2020-09-13  4:07                                 ` Richard Stallman
2020-09-29 10:05                               ` Thomas Plass
2020-10-01  1:45                                 ` Lars Ingebrigtsen
2020-10-01  1:50                                   ` Lars Ingebrigtsen
2020-10-01 13:38                                   ` Thomas Plass
2020-10-01 16:19                                     ` Ulf Jasper
2020-10-01 16:22                                       ` Lars Ingebrigtsen
2020-10-01 16:54                                         ` Ulf Jasper
2020-10-01 16:59                                           ` Lars Ingebrigtsen
2020-10-01 18:40                                             ` Ulf Jasper
2020-10-01 18:47                                               ` Lars Ingebrigtsen
2020-10-01 19:00                                                 ` Ulf Jasper
2020-10-01 18:49                                           ` Thomas Plass
2020-10-01 18:53                                             ` Thomas Plass
2020-10-01 19:14                                             ` Ulf Jasper
2020-10-10 20:06                                               ` Lars Ingebrigtsen
2020-10-22 15:50                                                 ` Ulf Jasper
2021-05-11 14:10                                                   ` Lars Ingebrigtsen
2021-07-29 14:55                                                     ` Ulf Jasper
2021-07-30 11:37                                                       ` Lars Ingebrigtsen
2023-10-01  2:12                                                 ` Stefan Kangas
2023-10-12 14:49                                                   ` Ulf Jasper
2023-10-15 14:28                                                     ` Stefan Kangas
2023-10-19 14:11                                                       ` Ulf Jasper
2023-12-24 14:02                                                         ` Stefan Kangas

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/emacs/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=24371.59842.984273.402129@AGAME7.local \
    --to=thunk2@arcor.de \
    --cc=34315@debbugs.gnu.org \
    --cc=larsi@gnus.org \
    --cc=ulf.jasper@web.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).