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 --]
next prev 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
* 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 external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.