Re: [os-libsynthesis] sending iCalendar 2.0 recurrence rule to Nokia phone: rule ignored (BMC #11241)
Hello Patrick, On Dec 14, 2010, at 16:38 , Patrick Ohly wrote: My suggestion (not tested yet) would be: From 08858608eeb252eef84b340ccc76f0b4f890a19d Mon Sep 17 00:00:00 2001 From: Lukas Zeller l...@synthesis.ch Date: Tue, 14 Dec 2010 15:53:28 +0100 Subject: [PATCH] engine: prevent generating invalid recurrence end specifications in vCalendar 1.0 RRULE (date-only not allowed, must be date+time) Almost works, except that the added time is truncated because the untilcontext still says date-only for the conversion. I've added one line (patch below) and commit an amended commit to the meego.gitorious.org repo. [... patch ...] Oops. Thanks for the fix! Lukas PS: regarding the map issues - I'm still investigating (and getting distracted by all sorts of things :-( ) ___ os-libsynthesis mailing list os-libsynthesis@synthesis.ch http://lists.synthesis.ch/mailman/listinfo/os-libsynthesis
Re: [os-libsynthesis] sending iCalendar 2.0 recurrence rule to Nokia phone: rule ignored (BMC #11241)
On Di, 2010-12-14 at 11:43 +, Lukas Zeller wrote: Hello Patrick, On Dec 13, 2010, at 13:22 , Patrick Ohly wrote: From http://bugs.meego.com/show_bug.cgi?id=11241. Problem summary below, patch attached. I'm a bit unsure about hard-coding UTC as time context in that code, please suggest how this might be improved. [... - stored in iCalendar 2.0 format as:] RRULE:FREQ=DAILY;INTERVAL=1;UNTIL=20111231T10 [... - rendered by libsynthesis as] RRULE:D1 20111231 [...] The spec says that the end date must contain a time: enddate::= ISO 8601_date_time value(e.g., 19940712T101530Z) I agree. There are no date-only values in vCalendar 1.0 at all. However what I don't understand is why and where the the original timestamp as represented by UNTIL=20111231T10 becomes a date-only value as shown in the vCalendar 1.0? IMHO, this should be a date+time long before it gets into mimedirprofile. So I'd like to understand why this happens in this case. I see however a case that needs some treatment - which is when a date-only iCalendar 2.0 is the input (which then also can have a date-only UNTIL= part in the RRULE). Such a record would be rendered incorrectly in vCalendar 1.0 (as date-only). That's exactly the situation here. The until date/time should IMHO be handled exactly like dates with the CONVMODE_AUTOENDDATE conversion mode, which renders date-only values as floating date+time in mimo_old (vCalendar xxx), but as date-only values in MIME-DIR (iCalendar 2.0). You are not suggesting to use convmode=auto[end]date as it is, right? If I read the documentation right, it will turn 20101231 into either 20101231T235959 (autoenddateinclusive) or 20101231T00. In both cases it would cut off the last occurrence on day 20101231. But I can see how converting to 20101231T235959 might work. My goal in the patch was to recreate exactly the same RRULE as sent by the Nokia phone, with the right time embedded in it. Not sure whether that is really necessary, perhaps something larger would also work. What time it should insert as fallback might be a bit tricky, but I think the start time of the event should do. My suggestion (I'll propose a patch soon) would be to make RR_END behave like CONVMODE_AUTOENDDATE to handle the case of an input timestamp which is a date-only. Okay. Let me know when it is ready and I'll redo my tests. -- Best Regards, Patrick Ohly The content of this message is my personal opinion only and although I am an employee of Intel, the statements I make here in no way represent Intel's position on the issue, nor am I authorized to speak on behalf of Intel on this matter. ___ os-libsynthesis mailing list os-libsynthesis@synthesis.ch http://lists.synthesis.ch/mailman/listinfo/os-libsynthesis
Re: [os-libsynthesis] sending iCalendar 2.0 recurrence rule to Nokia phone: rule ignored (BMC #11241)
Hello Patrick,
On Dec 14, 2010, at 12:59 , Patrick Ohly wrote:
The until date/time should IMHO be handled exactly like dates with the
CONVMODE_AUTOENDDATE conversion mode, which renders date-only values
as floating date+time in mimo_old (vCalendar xxx), but as date-only
values in MIME-DIR (iCalendar 2.0).
You are not suggesting to use convmode=auto[end]date as it is, right?
No, just similar in concept. Such that you can think more or less in iCalendar
2.0 (UNTIL can be date-only or date-time, depending whether the master is an
all-day or an appointment), and the engine will take care of representing it in
vCalendar 1.0.
If I read the documentation right, it will turn 20101231 into either
20101231T235959 (autoenddateinclusive) or 20101231T00.
20101230T235959, not 31st (typo assumed :-)
In both cases it would cut off the last occurrence on day 20101231.
Yes, that can't be applied 1:1 to UNTIL. I'd suggest that for an all-day the
vCalendar 1.0 representation would be 23:59:59 on that day (and not on the day
before as for DTEND). With this, the last occurrence will be included for
certain.
But I can see how converting to 20101231T235959 might work. My goal in
the patch was to recreate exactly the same RRULE as sent by the Nokia
phone, with the right time embedded in it. Not sure whether that is
really necessary, perhaps something larger would also work.
In my experience it works better with a generous recurrence end. I haven't met
a SyncML client having any problems with an recurrence end anywhere between the
last occurrence and the next date produced by the rule. But in a few cases I've
seen the opposite, implementations cutting off the last occurrence even if the
end date correctly matched DTSTART. So I think it's safe and most compatible to
send 23:59:59 for a vCalendar 1.0 allday.
My suggestion (I'll propose a patch soon) would be to make RR_END
behave like CONVMODE_AUTOENDDATE to handle the case of an input
timestamp which is a date-only.
Okay. Let me know when it is ready and I'll redo my tests.
My suggestion (not tested yet) would be:
From 08858608eeb252eef84b340ccc76f0b4f890a19d Mon Sep 17 00:00:00 2001
From: Lukas Zeller l...@synthesis.ch
Date: Tue, 14 Dec 2010 15:53:28 +0100
Subject: [PATCH] engine: prevent generating invalid recurrence end
specifications in vCalendar 1.0 RRULE (date-only not allowed, must be date+time)
For all-day entries, RR_END can become a date-only value
(for example when read in via iCalendar 2.0). Up to now,
rendering these as vCalendar 1.0 resulted in an invalid
RRULE containing a date-only recurrence end specification.
This patch makes sure the recurrence end specification
is always shown as a datetime (23:59:59 on the last
occurrence)
---
sysync/mimedirprofile.cpp |9 +
1 files changed, 9 insertions(+), 0 deletions(-)
diff --git a/sysync/mimedirprofile.cpp b/sysync/mimedirprofile.cpp
index 5d461f7..7db894a 100644
--- a/sysync/mimedirprofile.cpp
+++ b/sysync/mimedirprofile.cpp
@@ -1399,6 +1399,7 @@ bool TMimeDirProfileHandler::fieldToMIMEString(
case CONVMODE_AUTOENDDATE:
case CONVMODE_AUTODATE: // show date-only as date in iCal 2.0
(mimo_standard), but always as timestamp for vCal 1.0 (mimo_old)
if (fMimeDirMode==mimo_standard) goto timestamp; // use autodate if
MIME-DIR format is not vCal 1.0 style
+ // for vCal 1.0 style, always renders as timestamp (as date-only values
are not allowed there)
case CONVMODE_TIMESTAMP: // always show as timestamp
// get explictly as timestamp (even if field or field contents is date)
autodate = false; // do not show as date, even if it is a date-only
@@ -1715,8 +1716,16 @@ bool TMimeDirProfileHandler::fieldToMIMEString(
lineartime_t tzend = until;
// A RRULE with no end extends at least into current time (for tz range
update, see below)
if (until==noLinearTime) {
+ // no end, but we still need a range to generate time zones for
tzend = getSession()-getSystemNowAs(TCTX_UTC);
}
+ else {
+// Treat RR_END similar to CONVMODE_AUTODATE, i.e. prevent rendering a
date-only value in mimo_old (which is not correct according to the standard)
+if (TCTX_IS_DATEONLY(untilcontext) fMimeDirMode==mimo_old) {
+ // there are no date-only recurrence ends in vCalendar 1.0
+ until =
lineartime2dateonlyTime(until)+secondToLinearTimeFactor*SecsPerHour*24-1 ; //
make time part 23:59:59.999 of this day
+}
+ }
// Now do the conversion
bool ok;
if (fMimeDirMode==mimo_old) {
--
1.7.2.3+GitX
Best Regards,
Lukas
___
os-libsynthesis mailing list
os-libsynthesis@synthesis.ch
http://lists.synthesis.ch/mailman/listinfo/os-libsynthesis
[os-libsynthesis] sending iCalendar 2.0 recurrence rule to Nokia phone: rule ignored (BMC #11241)
Hello! From http://bugs.meego.com/show_bug.cgi?id=11241. Problem summary below, patch attached. I'm a bit unsure about hard-coding UTC as time context in that code, please suggest how this might be improved. - This was sent to us by the phone: BEGIN:VCALENDAR VERSION:1.0 TZ:+01 DAYLIGHT:TRUE;+02;20100328T01Z;20101031T01Z;; DAYLIGHT:TRUE;+02;20110327T01Z;20111030T01Z;; BEGIN:VEVENT SUMMARY:Phone DTSTART:20101212T09Z DTEND:20101212T09Z CLASS:PRIVATE RRULE:D1 20111231T10 AALARM;TYPE=X-EPOCSOUND:20101212T084500Z;;; LAST-MODIFIED:20101213T081626Z PRIORITY:2 END:VEVENT END:VCALENDAR Translated into: BEGIN:VCALENDAR VERSION:2.0 PRODID:-//Synthesis AG//NONSGML SyncML Engine V3.4.0.8//EN BEGIN:VTIMEZONE TZID:Europe/Zurich BEGIN:STANDARD DTSTART:19671029T03 RRULE:FREQ=MONTHLY;INTERVAL=12;BYDAY=-1SU TZOFFSETFROM:+0200 TZOFFSETTO:+0100 TZNAME:CET END:STANDARD BEGIN:DAYLIGHT DTSTART:19870329T02 RRULE:FREQ=MONTHLY;INTERVAL=12;BYDAY=-1SU TZOFFSETFROM:+0100 TZOFFSETTO:+0200 TZNAME:CEST END:DAYLIGHT END:VTIMEZONE BEGIN:VEVENT LAST-MODIFIED:20101213T081626Z CLASS:PRIVATE PRIORITY:2 SUMMARY:Phone DESCRIPTION:Phone DTSTART;TZID=Europe/Zurich:20101212T10 RRULE:FREQ=DAILY;INTERVAL=1;UNTIL=20111231T10 DTEND;TZID=Europe/Zurich:20101212T10 BEGIN:VALARM TRIGGER;VALUE=DATE-TIME:20101212T084500Z ACTION:DISPLAY END:VALARM END:VEVENT END:VCALENDAR After changing the summary, it is sent back to the phone as an update as: BEGIN:VCALENDAR VERSION:1.0 TZ:+01:00 DAYLIGHT;ENCODING=QUOTED-PRINTABLE:TRUE;+02;20110327T01Z;20111= 030T01Z;CET;CEST BEGIN:VEVENT LAST-MODIFIED:20101213T091201Z CLASS:PRIVATE PRIORITY:2 SUMMARY:Phone mod DESCRIPTION:Phone DTSTART:20101212T09Z RRULE:D1 20111231 DTEND:20101212T09Z AALARM:20101212T084500Z;;;Phone mod DALARM:20101212T084500Z;;;Phone mod END:VEVENT END:VCALENDAR One relevant difference might be the explicit time in the RRULE. The phone includes it, the Synthesis engine doesn't. Yep, that seems to be it. Both forever (RRULE:D1 #0) and fixed number of times work. The later one works because the Synthesis engine internally converts it into a fixed end date/time. The spec says that the end date must contain a time: enddate::= ISO 8601_date_time value(e.g., 19940712T101530Z) It does not say whether that end datetime is included in the recurrence, but experiments show that this is the interpretation on the phone (vCalendar 1.0) and in Evolution (iCalendar 2.0). Given that vCalendar does not allow floating end dates, I think the encoder for vCalendar RRULE should be fixed to not generate such broken rules. What time it should insert as fallback might be a bit tricky, but I think the start time of the event should do. -- Best Regards, Patrick Ohly The content of this message is my personal opinion only and although I am an employee of Intel, the statements I make here in no way represent Intel's position on the issue, nor am I authorized to speak on behalf of Intel on this matter. From 400b471a43d02dbcdf2c6affdde7ac1b1d7171a8 Mon Sep 17 00:00:00 2001 From: Patrick Ohly patrick.o...@intel.com Date: Mon, 13 Dec 2010 13:08:40 +0100 Subject: [PATCH] vCalendar 1.0: avoid RRULE end date without time When parsing an iCalendar 2.0 event, it is possible to arrive at an rrule until date/time which contains no time value. vCalendar 1.0 requires such a time. Not sending it, as the engine did before, causes Nokia phones to ignore the recurrence rule (bugs.meego.com #11241). This patch avoids this case by looking at the time of the event start and adds that time to the recurrence until date. The comment in the default config says: !-- recurrence rule block, fields must be in that order, including DTSTART as last field !! -- But it doesn't seem like DTSTART was really used before. Therefore this patch tries to deal with not finding a timestamp after the recurrence rule block by clearing the TCTX_DATEONLY, without actually setting a time. Probably not quite correct, but perhaps better than not changing anything. Another problematic aspect is to match the time zone context of the until clause with the start date/time of the event. Currently the patch assumes that the start time is going to be encoded as UTC. --- src/sysync/mimedirprofile.cpp | 30 ++ 1 files changed, 30 insertions(+), 0 deletions(-) diff --git a/src/sysync/mimedirprofile.cpp b/src/sysync/mimedirprofile.cpp index 2cbce65..1314240 100644 --- a/src/sysync/mimedirprofile.cpp +++ b/src/sysync/mimedirprofile.cpp @@ -1700,6 +1700,12 @@ bool TMimeDirProfileHandler::fieldToMIMEString( // - until if (!(tsFldP = ITEMFIELD_DYNAMIC_CAST_PTR(TTimestampField,fty_timestamp,aItem.getArrayField(aFid,aArrIndex,true return false; aFid++; // do NOT INCREMENT in macro, as it would get incremented twice + // - start time (according to comment for recurrence rule block, this must +
