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 >> 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 14:57 +, Lukas Zeller wrote:
> 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),
FWIW, the event in this case was not an all-day event, but Evolution
nevertheless used a date-only until value.
> > If I read the documentation right, it will turn 20101231 into either
> > 20101231T235959 () or 20101231T00.
>
> 20101230T235959, not 31st (typo assumed :-)
Yes.
> > 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.
Agreed. Seems that I was trying to hard when a simpler solution would
have worked just as well ;-)
> >> 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
> 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.
diff --git a/src/sysync/mimedirprofile.cpp b/src/sysync/mimedirprofile.cpp
index 6eb9790..27fcacb 100644
--- a/src/sysync/mimedirprofile.cpp
+++ b/src/sysync/mimedirprofile.cpp
@@ -1720,6 +1720,7 @@ bool TMimeDirProfileHandler::fieldToMIMEString(
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:5:
+ untilcontext &= ~TCTX_DATEONLY;
}
}
// Now do the conversion
--
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 () 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
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
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 () 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 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). 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). > 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). Yes, IMHO the end date is inclusive, and can be on the exact date of the last occurrence. I have seen implementations that require the entire duration of the last occurrence to be included, so I usually set RR_END to the DTEND, not DTSTART time. These types of shaping (there's other stuff that requires similar attention, like alarms etc.) are however too dependent on the backend, so that the place to do such things is either the backend itself or the . > 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. Certainly. This is a bug. > 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. However, this does not answer the original question why RR_END became a date-only in the example you showed. Best Regards, Lukas ___ os-libsynthesis mailing list os-libsynthesis@synthesis.ch http://lists.synthesis.ch/mailman/listinfo/os-libsynthesis
