[os-libsynthesis] wrong interpretation of timezone information
Hello! I have a meeting in my Evolution calendar which I synchronize with SyncEvolution. I noticed that the outgoing VEVENT has start and end time converted to UTC times which are one hour off. Here's the stripped down event: BEGIN:VCALENDAR PRODID:-//Ximian//NONSGML Evolution Calendar//EN VERSION:2.0 METHOD:PUBLISH BEGIN:VTIMEZONE TZID:GMT Standard Time BEGIN:STANDARD DTSTART:16010101T02 TZOFFSETFROM:+0100 TZOFFSETTO:+ RRULE:FREQ=YEARLY;BYDAY=-1SU;BYMONTH=10 END:STANDARD BEGIN:DAYLIGHT DTSTART:16010101T01 TZOFFSETFROM:+ TZOFFSETTO:+0100 RRULE:FREQ=YEARLY;BYDAY=-1SU;BYMONTH=3 END:DAYLIGHT END:VTIMEZONE BEGIN:VEVENT SUMMARY:test event DTSTART;TZID=GMT Standard Time:20100421T15 DTEND;TZID=GMT Standard Time:20100421T16 UID:04008200E00074C5B7101A82E00800B5A586D0A4CA0110 CLASS:PUBLIC PRIORITY:5 DTSTAMP:20100415T035521Z TRANSP:OPAQUE STATUS:CONFIRMED SEQUENCE:4 END:VEVENT END:VCALENDAR This is parsed into a field list as follows: - 18 : timestamp DTSTART [ 0, 0, 0] : 2010-04-21T15:00:00Z (TZ: UTC) - 19 : timestamp DTEND [ 0, 0, 0] : 2010-04-21T16:00:00Z (TZ: UTC) And then encoded like this when sent to the server: BEGIN:VCALENDAR VERSION:2.0 PRODID:-//Synthesis AG//NONSGML SyncML Engine V3.4.0.6//EN BEGIN:VEVENT STATUS:CONFIRMED LAST-MODIFIED:20100421T071812Z DTSTAMP:20100421T071905Z CREATED:20100415T065234Z UID:04008200E00074C5B7101A82E00800B5A586D0A4CA0110 CLASS:PUBLIC TRANSP:OPAQUE PRIORITY:5 SUMMARY:test event DTSTART:20100421T15Z DTEND:20100421T16Z END:VEVENT END:VCALENDAR The correct start time in UTC is 14:00, because this "GMT Standard Time" VTIMEZONE has a 1 hour offset during summer saving time. The event was created by Outlook. Any idea how that happens? -- 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] wrong interpretation of timezone information
On Wed, 2010-04-21 at 09:39 +0200, Patrick Ohly wrote:
> I have a meeting in my Evolution calendar which I synchronize with
> SyncEvolution. I noticed that the outgoing VEVENT has start and end
> time
> converted to UTC times which are one hour off.
>
> Here's the stripped down event:
>
> BEGIN:VCALENDAR
> PRODID:-//Ximian//NONSGML Evolution Calendar//EN
> VERSION:2.0
> METHOD:PUBLISH
> BEGIN:VTIMEZONE
> TZID:GMT Standard Time
> BEGIN:STANDARD
> DTSTART:16010101T02
> TZOFFSETFROM:+0100
> TZOFFSETTO:+
> RRULE:FREQ=YEARLY;BYDAY=-1SU;BYMONTH=10
> END:STANDARD
> BEGIN:DAYLIGHT
> DTSTART:16010101T01
> TZOFFSETFROM:+
> TZOFFSETTO:+0100
> RRULE:FREQ=YEARLY;BYDAY=-1SU;BYMONTH=3
> END:DAYLIGHT
> END:VTIMEZONE
> BEGIN:VEVENT
> SUMMARY:test event
> DTSTART;TZID=GMT Standard Time:20100421T15
> DTEND;TZID=GMT Standard Time:20100421T16
> UID:04008200E00074C5B7101A82E00800B5A586D0A4CA0110
> CLASS:PUBLIC
> PRIORITY:5
> DTSTAMP:20100415T035521Z
> TRANSP:OPAQUE
> STATUS:CONFIRMED
> SEQUENCE:4
> END:VEVENT
> END:VCALENDAR
This fails because RRULE2toInternal() in rrule.cpp fails to convert the
RRULE properties into the internal format. It bombs out here:
switch (freq)
{
...
case 'Y' :
if (byday == "" ||
(byday.length() == 2 && byday[0] ==
RRULE_weekdays[startwday][0] &&
byday[1] ==
RRULE_weekdays[startwday][1]))
{
...
}
else
{
goto incompat;
}
It reaches the "goto incompat" because byday == "-1SU".
Recurrence rules with "last day in month ..." are common for VTIMEZONEs.
Beat, is that really something that is not handled by the Synthesis code
at the moment? What would be necessary to add support for it?
--
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] wrong interpretation of timezone information
On Mon, 2010-04-26 at 13:40 +0100, Patrick Ohly wrote:
> On Wed, 2010-04-21 at 09:39 +0200, Patrick Ohly wrote:
> > I have a meeting in my Evolution calendar which I synchronize with
> > SyncEvolution. I noticed that the outgoing VEVENT has start and end
> > time
> > converted to UTC times which are one hour off.
> >
> > Here's the stripped down event:
> >
> > BEGIN:VCALENDAR
> > PRODID:-//Ximian//NONSGML Evolution Calendar//EN
> > VERSION:2.0
> > METHOD:PUBLISH
> > BEGIN:VTIMEZONE
> > TZID:GMT Standard Time
> > BEGIN:STANDARD
> > DTSTART:16010101T02
> > TZOFFSETFROM:+0100
> > TZOFFSETTO:+
> > RRULE:FREQ=YEARLY;BYDAY=-1SU;BYMONTH=10
> > END:STANDARD
> > BEGIN:DAYLIGHT
> > DTSTART:16010101T01
> > TZOFFSETFROM:+
> > TZOFFSETTO:+0100
> > RRULE:FREQ=YEARLY;BYDAY=-1SU;BYMONTH=3
> > END:DAYLIGHT
> > END:VTIMEZONE
> > BEGIN:VEVENT
> > SUMMARY:test event
> > DTSTART;TZID=GMT Standard Time:20100421T15
> > DTEND;TZID=GMT Standard Time:20100421T16
> > UID:04008200E00074C5B7101A82E00800B5A586D0A4CA0110
> > CLASS:PUBLIC
> > PRIORITY:5
> > DTSTAMP:20100415T035521Z
> > TRANSP:OPAQUE
> > STATUS:CONFIRMED
> > SEQUENCE:4
> > END:VEVENT
> > END:VCALENDAR
>
> This fails because RRULE2toInternal() in rrule.cpp fails to convert the
> RRULE properties into the internal format. It bombs out here:
>
> switch (freq)
> {
> ...
> case 'Y' :
> if (byday == "" ||
> (byday.length() == 2 && byday[0] ==
> RRULE_weekdays[startwday][0] &&
> byday[1] ==
> RRULE_weekdays[startwday][1]))
> {
> ...
> }
> else
> {
> goto incompat;
> }
>
> It reaches the "goto incompat" because byday == "-1SU".
>
> Recurrence rules with "last day in month ..." are common for VTIMEZONEs.
> Beat, is that really something that is not handled by the Synthesis code
> at the moment? What would be necessary to add support for it?
I'm still wondering about this.
In the meantime I looked into VTIMEZONEs which parse successfully. What
I found is that FREQ=YEARLY;BYDAY=-1SU;BYMONTH=10 (as in the example
above) is supported, by converting it to the equivalent
FREQ=MONTHLY;INTERVAL=12;BYDAY=-1SU.
However, there is a sanity check that compares the start month:
if (DayMonthCombi( freq, byday,bymonth,startmonth )) {
freq= 'M'; // a different model will be chosen for this case,
interval= 12*interval; // which is in fact aequivalent
bymonth = "";
} // if
In the example above, DTSTART=16010101T02 and thus startmonth !=
bymonth. DayMonthCombi() then returns false.
Does the month in DTSTART really matter in this case? I would expect
that the first recurrence will be in the month specified in BYMONTH
which is >= than the month in DTSTART, so one could apply the conversion
to FREQ=MONTHLY;INTERVAL=12;BYDAY=-1SU by setting the month in DTSTART
to the value from BYMONTH.
Does that make sense?
--
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] wrong interpretation of timezone information
Hello Patrick,
Thanks for the analysis. I changed the rrule parsing routine to allow returning
a adjusted DTSTART so the engine now correctly detects this iCalendar's
timezone as GMT. I just pushed these changes into the luz branch on synthesis
indefero.
Best Regards,
Lukas
On May 4, 2010, at 22:40 , Patrick Ohly wrote:
> On Mon, 2010-04-26 at 13:40 +0100, Patrick Ohly wrote:
>> On Wed, 2010-04-21 at 09:39 +0200, Patrick Ohly wrote:
>>> I have a meeting in my Evolution calendar which I synchronize with
>>> SyncEvolution. I noticed that the outgoing VEVENT has start and end
>>> time
>>> converted to UTC times which are one hour off.
>>>
>>> Here's the stripped down event:
>>>
>>> BEGIN:VCALENDAR
>>> PRODID:-//Ximian//NONSGML Evolution Calendar//EN
>>> VERSION:2.0
>>> METHOD:PUBLISH
>>> BEGIN:VTIMEZONE
>>> TZID:GMT Standard Time
>>> BEGIN:STANDARD
>>> DTSTART:16010101T02
>>> TZOFFSETFROM:+0100
>>> TZOFFSETTO:+
>>> RRULE:FREQ=YEARLY;BYDAY=-1SU;BYMONTH=10
>>> END:STANDARD
>>> BEGIN:DAYLIGHT
>>> DTSTART:16010101T01
>>> TZOFFSETFROM:+
>>> TZOFFSETTO:+0100
>>> RRULE:FREQ=YEARLY;BYDAY=-1SU;BYMONTH=3
>>> END:DAYLIGHT
>>> END:VTIMEZONE
>>> BEGIN:VEVENT
>>> SUMMARY:test event
>>> DTSTART;TZID=GMT Standard Time:20100421T15
>>> DTEND;TZID=GMT Standard Time:20100421T16
>>> UID:04008200E00074C5B7101A82E00800B5A586D0A4CA0110
>>> CLASS:PUBLIC
>>> PRIORITY:5
>>> DTSTAMP:20100415T035521Z
>>> TRANSP:OPAQUE
>>> STATUS:CONFIRMED
>>> SEQUENCE:4
>>> END:VEVENT
>>> END:VCALENDAR
>>
>> This fails because RRULE2toInternal() in rrule.cpp fails to convert the
>> RRULE properties into the internal format. It bombs out here:
>>
>> switch (freq)
>> {
>> ...
>>case 'Y' :
>> if (byday == "" ||
>> (byday.length() == 2 && byday[0] ==
>> RRULE_weekdays[startwday][0] &&
>> byday[1] ==
>> RRULE_weekdays[startwday][1]))
>> {
>> ...
>> }
>> else
>> {
>>goto incompat;
>> }
>>
>> It reaches the "goto incompat" because byday == "-1SU".
>>
>> Recurrence rules with "last day in month ..." are common for VTIMEZONEs.
>> Beat, is that really something that is not handled by the Synthesis code
>> at the moment? What would be necessary to add support for it?
>
> I'm still wondering about this.
>
> In the meantime I looked into VTIMEZONEs which parse successfully. What
> I found is that FREQ=YEARLY;BYDAY=-1SU;BYMONTH=10 (as in the example
> above) is supported, by converting it to the equivalent
> FREQ=MONTHLY;INTERVAL=12;BYDAY=-1SU.
>
> However, there is a sanity check that compares the start month:
> if (DayMonthCombi( freq, byday,bymonth,startmonth )) {
>freq= 'M'; // a different model will be chosen for this case,
>interval= 12*interval; // which is in fact aequivalent
>bymonth = "";
> } // if
>
> In the example above, DTSTART=16010101T02 and thus startmonth !=
> bymonth. DayMonthCombi() then returns false.
>
> Does the month in DTSTART really matter in this case? I would expect
> that the first recurrence will be in the month specified in BYMONTH
> which is >= than the month in DTSTART, so one could apply the conversion
> to FREQ=MONTHLY;INTERVAL=12;BYDAY=-1SU by setting the month in DTSTART
> to the value from BYMONTH.
>
> Does that make sense?
>
> --
> 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
Lukas Zeller (l...@synthesis.ch)
-
Synthesis AG, SyncML Solutions & Sustainable Software Concepts
i...@synthesis.ch, http://www.synthesis.ch
___
os-libsynthesis mailing list
os-libsynthesis@synthesis.ch
http://lists.synthesis.ch/mailman/listinfo/os-libsynthesis
Re: [os-libsynthesis] wrong interpretation of timezone information
On Fri, 2010-05-07 at 12:53 +0100, Lukas Zeller wrote: > Thanks for the analysis. I changed the rrule parsing routine to allow > returning a adjusted DTSTART so the engine now correctly detects this > iCalendar's timezone as GMT. I just pushed these changes into the luz > branch on synthesis indefero. Confirmed, works for me. I should have mentioned that I had already made similar changes as you on the moblin.org master branch (check for NULL obj in debug macros, enable debug logging inside vtimezone code when invoked by mimedir profile parser). My own debug logging patches go a bit further: - log an error when parsing a VTIMEZONE fails - logging of libical timezone conversion - logging of timezone matching I'm trying to track down an unexpected timezone failure with this which occurs when normal Evolution events are involved. Do you agree with these changes? Would you mind merging them? I rebased them on your "luz" branch. -- 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] wrong interpretation of timezone information
Hi Patrick, On May 10, 2010, at 9:04 , Patrick Ohly wrote: > Confirmed, works for me. Thanks! > I should have mentioned that I had already made similar changes as you > on the moblin.org master branch (check for NULL obj in debug macros, > enable debug logging inside vtimezone code when invoked by mimedir > profile parser). > > My own debug logging patches go a bit further: > - log an error when parsing a VTIMEZONE fails > - logging of libical timezone conversion > - logging of timezone matching > > I'm trying to track down an unexpected timezone failure with this which > occurs when normal Evolution events are involved. > > Do you agree with these changes? Would you mind merging them? I rebased > them on your "luz" branch. The attempt to init the time zones after reading config (fc000b0f45 (TSyncAppBase: moved system time zone parsing after config reading)) creates a chicken and egg problem. The config reading process relies itself on the time zone stuff being initialized, most prominently for , but also for other tags that have ISO8601 timestamp values. Maybe the dilemma can be solved by adding an optional, second initialize run after config reading that can be switched on specifically to track down timezone init problems. Another option would be to use the ConferrPuts() channel, which is ready before config is read by definition. Best Regards, Lukas Zeller (l...@synthesis.ch) - Synthesis AG, SyncML Solutions & Sustainable Software Concepts i...@synthesis.ch, http://www.synthesis.ch ___ os-libsynthesis mailing list os-libsynthesis@synthesis.ch http://lists.synthesis.ch/mailman/listinfo/os-libsynthesis
Re: [os-libsynthesis] wrong interpretation of timezone information
On Mon, 2010-05-10 at 16:48 +0100, Lukas Zeller wrote: > Hi Patrick, > > On May 10, 2010, at 9:04 , Patrick Ohly wrote: > > > Confirmed, works for me. > > Thanks! > > > I should have mentioned that I had already made similar changes as you > > on the moblin.org master branch (check for NULL obj in debug macros, > > enable debug logging inside vtimezone code when invoked by mimedir > > profile parser). > > > > My own debug logging patches go a bit further: > > - log an error when parsing a VTIMEZONE fails > > - logging of libical timezone conversion > > - logging of timezone matching > > > > I'm trying to track down an unexpected timezone failure with this which > > occurs when normal Evolution events are involved. > > > > Do you agree with these changes? Would you mind merging them? I rebased > > them on your "luz" branch. > > The attempt to init the time zones after reading config (fc000b0f45 > (TSyncAppBase: moved system time zone parsing after config reading)) > creates a chicken and egg problem. The config reading process relies > itself on the time zone stuff being initialized, most prominently for > , but also for other tags that have ISO8601 timestamp > values. I see. > Maybe the dilemma can be solved by adding an optional, second > initialize run after config reading that can be switched on > specifically to track down timezone init problems. That would imply redoing some of the work. What about the following (code in master, as I need to fix that anyway): commit 7bbec4fd20cde059973d4d1c840fcee85d947e60 Author: Patrick Ohly Date: Tue May 11 16:57:35 2010 +0200 time zone init and logging: split into part before and after config parsing This patch reverts the "move system time zone parsing after config reading" part of commit fc000b0f45. As Lukas pointed out, config parsing already depends on time zones, for example for . But this patch keeps the finishConfig() callback and uses it to invoke a second global time zone function. On Linux, that function is used to add the libical time zone definitions and logs them at the same time. Builtin time zones are added at the original time, before parsing the config. This is a compromise between having no time zones while parsing the config and not logging the libical time zones. It works for SyncEvolution, because it doesn't reference the additional time zones in the config. > Another option would be to use the ConferrPuts() channel, which is > ready before config is read by definition. That won't help, because I need this information in the normal log file to simplify remote debugging. -- 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
