Menu
▾
▴
#91 vevent start before vtimezone switches uses UTC instead
The iPhone and other apple products send timezone information for a meeting using the current year. Since the first switch of a normal timezone occurs somewhere in march, all events created between 1 jan and the switch will be converted incorrectly in libical.
Example:
----
BEGIN:VCALENDAR
CALSCALE:GREGORIAN
METHOD:REQUEST
PRODID:-//Apple Inc.//iPhone 3.0//EN
VERSION:2.0
BEGIN:VTIMEZONE
TZID:Europe/Amsterdam
BEGIN:DAYLIGHT
DTSTART:20130331T020000
RRULE:FREQ=YEARLY;BYMONTH=3;BYDAY=-1SU
TZNAME:CEST
TZOFFSETFROM:+0100
TZOFFSETTO:+0200
END:DAYLIGHT
BEGIN:STANDARD
DTSTART:20131027T030000
RRULE:FREQ=YEARLY;BYMONTH=10;BYDAY=-1SU
TZNAME:CET
TZOFFSETFROM:+0200
TZOFFSETTO:+0100
END:STANDARD
END:VTIMEZONE
BEGIN:VEVENT
ATTENDEE;CN="someone@somewhere.com";CUTYPE=INDIVIDUAL;PARTSTAT=NEEDS-ACTION;RS
VP=TRUE:mailto:someone@somewhere.com
CREATED:20130131T100140Z
DESCRIPTION:Meet me
DTEND;TZID=Europe/Amsterdam:20130131T130000
DTSTAMP:20130131T100141Z
DTSTART;TZID=Europe/Amsterdam:20130131T120000
LAST-MODIFIED:20130131T100141Z
LOCATION:Anywhere
ORGANIZER;CN="anybody":mailto:anybody@somewhere.com
SEQUENCE:0
SUMMARY:subject
TRANSP:OPAQUE
UID:C3684E8472CE477BAB99A16E55A61A9600000000000000000000000000000000
X-MICROSOFT-CDO-INTENDEDSTATUS:BUSY
END:VEVENT
END:VCALENDAR
----
Here the DTSTART of the VEVENT on 31 jan is before the daylight switch mentioned in the vtimezone definition.
Now when calling icaltime_as_timet_with_zone with the DTSTART and the timezone it's defined in will return the same time (12 o'clock) as the utc time, which is wrong. This is because icaltimezone_get_utc_offset did not expand 2012, and so the loop there will not find a match. In that case it will just return UTC. Which is probably the worst value to return.
I attached a patch which will return the prev_utc_offset for this case instead of UTC, which I think is a better probability of being correct. Ofcourse you could make an item where the DTSTART of the item is far before the given timezone, but that case would be very weird for clients to send. For that case the expantion code would need to be fixed to be able to search before, and not after.
John,
I'm curious why this patch against the very old libical 0.44. Any reason why you aren't using a more modern version, like 0.48?
Any chance you could test against version 0.48 .. just to make sure we still have this bug and still need your patch
-Allen
The code in 0.48 and 0.44 in this case is the same. The patch applies cleanly there too.
Thanks John.
Committed with revision 1141