Recent changes to bugs

Time zone expansion omits current date

padarlin — Mon, 08 Feb 2010 23:17:54 -0000

Issue seen with all libical versions, including 0.44.
Test case iCal data :
1.VEVENT DTSTART and DTEND includes a TZID tag.
2.VTIMEZONE defines a TZID that has DAYLIGHT and STANDARD data, each of which defines a RRULE and DTSTART.
3.DTSTART in both STANDARD and DAYLIGHT data is ahead of the DTSTART date of the VEVENT. This is occurring for events that start before the first offset switch of the year, prior to the DST switch over (i.e. first few months of the year).

Time zone expansion performed by libical starts from the current year + 5 years. This leads to the VEVENT start date falling before the first time zone change in the zone->changes array, and the offset is returned as 0.

The expanded time zone changes should include the most recent change prior to the VEVENT start date (in this case from the prior year) so that the offset is calculated correctly for the start date.

The expanded time zone changes should include the most recent change prior to the VEVENT start date, so that the offset is calculated correctly for this start date.

icalparser_parse returning NULL value pointer

Marco Meier — Mon, 21 Sep 2009 13:16:03 -0000

i got a mail with an event invitation which looked like

ATTENDEE;CN="Name";CUTYPE=INDIVIDUAL;EMAIL="Name@domain.
tld";PARTSTAT=NEEDS-ACTION;ROLE=REQ-PARTICIPANT;RSVP=TRUE:mailto:Na
me@domain.tld

if there is a space after the newline inside "" (as it is at the email tag),
icalparser_parse returns an icalcomponent with a value which points to NULL.
when removing the space at the beginning of that line, everything works fine.

DTSTART in VTIMEZONE wrong?

Patrick Ohly — Thu, 20 Nov 2008 12:41:41 -0000

Hello!

While we were doing interoperability tests between SyncEvolution (using Evolution 2.22.3.1 libical) and the Synthesis server, Lukas Zeller noticed a problem.

The VTIMEZONE's generated by libical have the DTSTART values for the daylight saving time and normal time swapped. According to Lukas (I haven't checked, but I trust his expertise in this area), the standard is a bit vague but is commonly understood as "DTSTART time relative to the local time before the switch".

libical with and without Chenthills patch does it the other way around and specifies DTSTART relative to the local time after the switch. Here's an old example, generated without Chenthill's patch:

TZID:/softwarestudio.org/Olson_20011030_5/Europe/Berlin
X-LIC-LOCATION:Europe/Berlin
BEGIN:DAYLIGHT
TZOFFSETFROM:+0100
TZOFFSETTO:+0200
TZNAME:CEST
DTSTART:19700329T020000
RRULE:FREQ=YEARLY;INTERVAL=1;BYDAY=-1SU;BYMONTH=3
END:DAYLIGHT
BEGIN:STANDARD
TZOFFSETFROM:+0200
TZOFFSETTO:+0100
TZNAME:CET
DTSTART:19701025T030000
RRULE:FREQ=YEARLY;INTERVAL=1;BYDAY=-1SU;BYMONTH=10
END:STANDARD
END:VTIMEZONE

Here's an example as currently generated by libical:
BEGIN:VTIMEZONE
TZID:/softwarestudio.org/Tzfile/Europe/Berlin
X-LIC-LOCATION:Europe/Berlin
BEGIN:STANDARD
TZNAME:CET
DTSTART:19701025T020000
RRULE:FREQ=YEARLY;INTERVAL=1;BYDAY=-1SU;BYMONTH=10
TZOFFSETFROM:+0200
TZOFFSETTO:+0100
END:STANDARD
BEGIN:DAYLIGHT
TZNAME:CEST
DTSTART:19700329T030000
RRULE:FREQ=YEARLY;INTERVAL=1;BYDAY=-1SU;BYMONTH=3
TZOFFSETFROM:+0100
TZOFFSETTO:+0200
END:DAYLIGHT
END:VTIMEZONE

Here's how Microsoft Exchange defines the same time zone:
PRODID:Microsoft Exchange Server 2007
BEGIN:VTIMEZONE
TZID:W. Europe Standard Time
BEGIN:STANDARD
DTSTART:16010101T030000
TZOFFSETFROM:+0200
TZOFFSETTO:+0100
RRULE:FREQ=YEARLY;INTERVAL=1;BYDAY=-1SU;BYMONTH=10
END:STANDARD
BEGIN:DAYLIGHT
DTSTART:16010101T020000
TZOFFSETFROM:+0100
TZOFFSETTO:+0200
RRULE:FREQ=YEARLY;INTERVAL=1;BYDAY=-1SU;BYMONTH=3
END:DAYLIGHT
END:VTIMEZONE

Any thoughts?

The test program that I wrote for Chenthill's system time zone conversion doesn't cover this detail. It only checks on specific days. Perhaps someone can improve it so that it checks each hour before and after the switch?

Where is icaltime_as_utc?

James Hanley — Mon, 27 Oct 2008 21:14:28 -0000

Can't find the definition or prototype for this in the c header files nor source.