From: John Hamelink <me@johnhame.link>
To: 54939@debbugs.gnu.org
Subject: bug#54939: 29.0.50; icalendar cannot infer the DTEND from DTSTART + DURATION
Date: Thu, 14 Apr 2022 14:44:16 +0100 [thread overview]
Message-ID: <87fsmfoi0f.fsf@johnhame.link> (raw)
[-- Attachment #1: Type: text/plain, Size: 7222 bytes --]
Hi there,
As part of my ongoing efforts to move entirely to Emacs for email, I've
discovered an incompatibility with calendar invites sent by Fastmail.
After triggering `mu4e-headers-view-message' from `mu4e-headers-mode', I
receive the following:
Debugger entered--Lisp error: (wrong-type-argument consp nil)
gnus-icalendar-event--decode-datefield((VEVENT nil ((UID nil
"064fa1da-e6f1-4463-9f5d-97217cde2c17") (SEQUENCE nil "1") (DTSTAMP
nil "20220414T130209Z") (CREATED nil "20220414T130209Z") (DTSTART
(TZID "Europe/London") "20220415T090000") (DURATION nil "PT1H")
(PRIORITY nil "0") (SUMMARY nil "Demo Event") (STATUS nil "CONFIRMED")
(TRANSP nil "OPAQUE") (ORGANIZER (X-JMAP-ID "bWVAam9obmhhbWUubGluaw"
CN "John Hamelink" EMAIL "me@johnhame.link")
"mailto:me@johnhame.link") (ATTENDEE (X-JMAP-ID
"bWVAam9obmhhbWUubGluaw" CN "John Hamelink" EMAIL "me@johnhame.link"
CUTYPE "INDIVIDUAL" X-JMAP-ROLE "owner" X-JMAP-ROLE "attendee"
PARTSTAT "ACCEPTED" RSVP "FALSE") "mailto:me@johnhame.link") (ATTENDEE
(X-JMAP-ID "am9obkBtZWRpY2NyZWF0aW9ucy5jb20" CN "John Hamelink" EMAIL
"john@work.com" CUTYPE "INDIVIDUAL" X-JMAP-ROLE "attendee" PARTSTAT
"NEEDS-ACTION" RSVP "TRUE") "mailto:john@work.com")) nil) DTEND
(("Europe/London"
. "STD-00:00DST-01:00,M3.5.0/01:00:00,M10.5.0/02:00:00")))
This makes sense, because on inspection of the ics file, we see that
DTEND is not part of the file (I added indentation to clarify scope):
BEGIN:VCALENDAR
VERSION:2.0
PRODID:-//CyrusIMAP.org/Cyrus=20
3.7.0-alpha0-387-g7ea99c4045-fm-20220413.002-g7ea99c40//EN
METHOD:REQUEST
CALSCALE:GREGORIAN
BEGIN:VTIMEZONE
TZID:Europe/London
LAST-MODIFIED:20210816T175139Z
X-LIC-LOCATION:Europe/London
TZUNTIL:20220415T090000Z
BEGIN:DAYLIGHT
TZNAME:BST
TZOFFSETFROM:+0000
TZOFFSETTO:+0100
DTSTART:19810329T010000
RRULE:FREQ=3DYEARLY;BYMONTH=3D3;BYDAY=3D-1SU
END:DAYLIGHT
BEGIN:STANDARD
TZNAME:GMT
TZOFFSETFROM:+0100
TZOFFSETTO:+0000
DTSTART:19961027T020000
RRULE:FREQ=3DYEARLY;BYMONTH=3D10;BYDAY=3D-1SU
END:STANDARD
END:VTIMEZONE
BEGIN:VEVENT
UID:064fa1da-e6f1-4463-9f5d-97217cde2c17
SEQUENCE:1
DTSTAMP:20220414T130209Z
CREATED:20220414T130209Z
DTSTART;TZID=3DEurope/London:20220415T090000
DURATION:PT1H
PRIORITY:0
SUMMARY:Demo Event
STATUS:CONFIRMED
TRANSP:OPAQUE
ORGANIZER;X-JMAP-ID=3DbWVAam9obmhhbWUubGluaw;CN=3DJohn Hamelink;
EMAIL=3Dme@johnhame.link:mailto:me@johnhame.link
ATTENDEE;X-JMAP-ID=3DbWVAam9obmhhbWUubGluaw;CN=3DJohn Hamelink;
EMAIL=3Dme@johnhame.link;CUTYPE=3DINDIVIDUAL;X-JMAP-ROLE=3Downer;
X-JMAP-ROLE=3Dattendee;PARTSTAT=3DACCEPTED;RSVP=3DFALSE:mailto:
me@johnhame.link
ATTENDEE;X-JMAP-ID=3Dam9obkBtZWRpY2NyZWF0aW9ucy5jb20;CN=3DJohn Hamelink;
EMAIL=3Djohn@work.com;CUTYPE=3DINDIVIDUAL;X-JMAP-ROLE=3Dattendee;
PARTSTAT=3DNEEDS-ACTION;RSVP=3DTRUE:mailto:john@work.com
END:VEVENT
END:VCALENDAR
However, it seems that from the ics file we did receive, we should be
able to infer the DTEND value by simply adding DURATION to DTSTART.
I've been able to setup a minimal configuration which replicates the
problem using the icalendar file above (and without involving mu4e):
(package-install 'gnus)
(package-install 'org)
(require 'gnus)
(require 'gnus-icalendar)
(setq-default gnus-icalendar-org-capture-file "/tmp/agenda.org"
gnus-icalendar-org-capture-headline '("Calendar"))
(gnus-icalendar-org-setup)
(gnus-icalendar-event-from-ical
'((VCALENDAR nil
((VERSION nil "2.0")
(PRODID nil "-//CyrusIMAP.org/Cyrus 3.7.0-alpha0-387-g7ea99c4045-fm-20220413.002-g7ea99c40//EN")
(METHOD nil "REQUEST")
(CALSCALE nil "GREGORIAN"))
((VTIMEZONE nil
((TZID nil "Europe/London")
(LAST-MODIFIED nil "20210816T175139Z")
(X-LIC-LOCATION nil "Europe/London")
(TZUNTIL nil "20220415T090000Z"))
((DAYLIGHT nil (... ... ... ... ...) nil)
(STANDARD nil (... ... ... ... ...) nil)))
(VEVENT nil (
(UID nil "064fa1da-e6f1-4463-9f5d-97217cde2c17")
(SEQUENCE nil "1")
(DTSTAMP nil "20220414T130209Z")
(CREATED nil "20220414T130209Z")
(DTSTART (TZID "Europe/London") "20220415T090000")
(DURATION nil "PT1H")
(PRIORITY nil "0")
(SUMMARY nil "Demo Event")
(STATUS nil "CONFIRMED")
(TRANSP nil "OPAQUE")
(ORGANIZER
(X-JMAP-ID "bWVAam9obmhhbWUubGluaw"
CN "John Hamelink"
EMAIL "me@johnhame.link") "mailto:me@johnhame.link")
(ATTENDEE
(X-JMAP-ID "bWVAam9obmhhbWUubGluaw"
CN "John Hamelink"
EMAIL "me@johnhame.link"
CUTYPE "INDIVIDUAL"
X-JMAP-ROLE "owner"
X-JMAP-ROLE "attendee"
PARTSTAT "ACCEPTED"
RSVP "FALSE") "mailto:me@johnhame.link")
(ATTENDEE
(X-JMAP-ID "am9obkBtZWRpY2NyZWF0aW9ucy5jb20"
CN "John Hamelink"
EMAIL "john@work.com"
CUTYPE "INDIVIDUAL"
X-JMAP-ROLE "attendee"
PARTSTAT "NEEDS-ACTION"
RSVP "TRUE") "mailto:john@work.com")) nil)))))
The part of the code which handles the end time is gnus-icalendar.el
line 246, where the code simply assumes that the DTEND property exists:
:end-time (gnus-icalendar-event--decode-datefield event 'DTEND zone-map)
RFC5545 Section 3.6.1 (the iCalendar spec) says:
; Either 'dtend' or 'duration' MAY appear in
; a 'eventprop', but 'dtend' and 'duration'
; MUST NOT occur in the same 'eventprop'.
And further on:
For cases where a "VEVENT" calendar component
specifies a "DTSTART" property with a DATE value type but no
"DTEND" nor "DURATION" property, the event's duration is taken to
be one day. For cases where a "VEVENT" calendar component
specifies a "DTSTART" property with a DATE-TIME value type but no
"DTEND" property, the event ends on the same calendar date and
time of day specified by the "DTSTART" property.
So, I propose we build a function that either returns the end-time using
DTEND as is currently the case, or else to add DTSTART + DURATION and
use that as DTEND if one doesn't exist, or else to use DTSTART + 1 Day
if DTSTART is a date, or else to use DTSTART if DTSTART is a datetime.
How does that sound?
Best,
JH
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 857 bytes --]
next reply other threads:[~2022-04-14 13:44 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-04-14 13:44 John Hamelink [this message]
2022-04-14 14:53 ` bug#54939: 29.0.50; icalendar cannot infer the DTEND from DTSTART + DURATION Lars Ingebrigtsen
2022-04-14 19:09 ` John Hamelink
2022-04-15 9:39 ` John Hamelink
2022-04-17 18:00 ` Paul Eggert
2022-04-18 19:50 ` John Hamelink
2022-04-25 10:50 ` John Hamelink
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=87fsmfoi0f.fsf@johnhame.link \
--to=me@johnhame.link \
--cc=54939@debbugs.gnu.org \
/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).