Friday Jan 30, 2009

VTODO with DUE date in Lightning

Lightning 0.9 also let you create VTODOs (Tasks) and store them on a CalDAV Server. By default those tasks have no associated dates but one can add a due date + time:

Here is how such a task is stored on the CalDAV server:

...
DUE;TZID=Europe/Paris:20090129T160000
... 

The VTODO component has a correct DUE property and no DTSTART.

If one tries to add an alarm to this task (trigger -15 minutes before), the start time of the task which was unset becomes auto selected and can not be removed (although it can be changed):

Here is how the VTODO is stored on the CalDAV Server:

...
DTSTART;TZID=Europe/Paris:20090129T160000
DUE;TZID=Europe/Paris:20090129T160000
BEGIN:VALARM
TRIGGER;VALUE=DURATION:-PT15M
DESCRIPTION:Mozilla Alarm: New Task
ACTION:DISPLAY
END:VALARM
...

Here again, the TRIGGER property is missing a RELATED=END parameter to indicate that the alarm is relative to the due date. Instead, a DTSTART was added, "without the user's consent".

In addition, given that the DTSTART value is equal to the DUE value, this component is valid per RFC2445 but invalid per the new calsify spec where the DUE value must be later in time than the value of the DTSTART.

I should have started by stating that I'm not trying to put any judgment on the quality of one implementation over another but rather to see how todos with due date are used by clients, how they can interoperate, and maybe help future client implementations.


Thursday Jan 29, 2009

VTODO with DUE date in Apple iCal

Following my previous post, I've started to look at how due dates are leveraged by real clients, starting with Apple iCal.

Apple iCal (on Mac OS 10.5) let you create VTODOs ("To Do Items") and store them on a CalDAV Server. By default those todos have no associated dates but one can add a due date (no time):

Here is how such a todo is stored on the CalDAV server:

...
DTSTART;TZID=Europe/Paris:20040101T120000
DUE;VALUE=DATE:20090127
... 

The VTODO component has a correct DUE property but it also has a DTSTART property which:

  1. comes out of nowhere (not visible in the UI),
  2. has no meaningful value (value hardcoded to 01/01/2004).

Client that takes the DTSTART into consideration to do some processing (e.g. to build a view) might show inconsistent results when processing such a VTODO.

Worth, the DTSTART property has a DATETIME value when the DUE property has a DATE value, causing the VTODO to be invalid per the new calsify spec.

If one tries to add an alarm (trigger -15 minutes before), the VTODO is stored as:

...
DTSTART;TZID=Europe/Paris:20040101T120000
DUE;VALUE=DATE:20090127
BEGIN:VALARM
X-WR-ALARMUID:5874F585-58CD-4357-88CF-951AEAF8663A
ACTION:AUDIO
TRIGGER:-PT15M
ATTACH;VALUE=URI:Basso
END:VALARM
... 

The TRIGGER property is missing a RELATED=END parameter which would link the alarm time to the DUE date. As a consequence, other clients will consider the TRIGGER to be relative to the DTSTART property. Since its value is meaningless (some time in 2004), the alarm will probably disappear (or be triggered as soon as the client fetches the todo).

About

arnaudq

Search

Archives
« April 2014
SunMonTueWedThuFriSat
  
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
   
       
Today
Bookmarks