headers
Patrick Ohly | 26 Apr 2010 14:40
Picon
Favicon
Gravatar

Re: 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:16010101T020000
> TZOFFSETFROM:+0100
> TZOFFSETTO:+0000
> RRULE:FREQ=YEARLY;BYDAY=-1SU;BYMONTH=10
> END:STANDARD
> BEGIN:DAYLIGHT
> DTSTART:16010101T010000
> TZOFFSETFROM:+0000
> TZOFFSETTO:+0100
> RRULE:FREQ=YEARLY;BYDAY=-1SU;BYMONTH=3
> END:DAYLIGHT
> END:VTIMEZONE
> BEGIN:VEVENT
> SUMMARY:test event
> DTSTART;TZID=GMT Standard Time:20100421T150000
(Continue reading)

Permalink | Reply |
headers
Patrick Ohly | 4 May 2010 22:40
Picon
Favicon
Gravatar

Re: 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:16010101T020000
> > TZOFFSETFROM:+0100
> > TZOFFSETTO:+0000
> > RRULE:FREQ=YEARLY;BYDAY=-1SU;BYMONTH=10
> > END:STANDARD
> > BEGIN:DAYLIGHT
> > DTSTART:16010101T010000
> > TZOFFSETFROM:+0000
> > TZOFFSETTO:+0100
> > RRULE:FREQ=YEARLY;BYDAY=-1SU;BYMONTH=3
> > END:DAYLIGHT
> > END:VTIMEZONE
> > BEGIN:VEVENT
> > SUMMARY:test event
(Continue reading)

Permalink | Reply |
headers
Lukas Zeller | 7 May 2010 13:53
Picon
Favicon
Gravatar

Re: 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:16010101T020000
>>> TZOFFSETFROM:+0100
(Continue reading)

Permalink | Reply |
headers
Patrick Ohly | 10 May 2010 09:04
Picon
Favicon
Gravatar

Re: 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
(Continue reading)

Permalink | Reply |
headers
Lukas Zeller | 10 May 2010 17:48
Picon
Favicon
Gravatar

Re: 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 <definetimezone>, 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
(Continue reading)

Permalink | Reply |
headers
Patrick Ohly | 11 May 2010 17:04
Picon
Favicon
Gravatar

Re: 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
> <definetimezone>, but also for other tags that have ISO8601 timestamp
(Continue reading)

Permalink | Reply |

Gmane