After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 574670 - Evolution calendar is starting the 2009 DST one week later than it should in Americas
Evolution calendar is starting the 2009 DST one week later than it should in ...
Status: RESOLVED NOTGNOME
Product: evolution-data-server
Classification: Platform
Component: libical
2.22.x (obsolete)
Other All
: Normal major
: ---
Assigned To: evolution-calendar-maintainers
Evolution QA team
Depends on:
Blocks:
 
 
Reported: 2009-03-09 19:14 UTC by James Bottomley
Modified: 2009-03-09 22:59 UTC
See Also:
GNOME target: ---
GNOME version: 2.21/2.22


Attachments
Fix for the problem (1.01 KB, patch)
2009-03-09 21:03 UTC, James Bottomley
none Details | Review

Description James Bottomley 2009-03-09 19:14:37 UTC
Please describe the problem:
Currently the system date is:

Mon Mar  9 14:05:01 CDT 2009

(I'm in America/Chicago), which is correct.  However, evolution calendar still has me in standard not daylight time.  If I dump the tzrules the system has compiled, I get:

BEGIN:VTIMEZONE
TZID:/softwarestudio.org/Tzfile/America/Chicago
X-LIC-LOCATION:America/Chicago
BEGIN:STANDARD
TZNAME:CST
DTSTART:19701101T010000
RRULE:FREQ=YEARLY;INTERVAL=1;BYDAY=1SU;BYMONTH=11
TZOFFSETFROM:-0500
TZOFFSETTO:-0600
END:STANDARD
BEGIN:DAYLIGHT
TZNAME:CDT
DTSTART:19700314T030000
RRULE:FREQ=YEARLY;INTERVAL=1;BYDAY=3SU;BYMONTH=3
TZOFFSETFROM:-0600
TZOFFSETTO:-0500
END:DAYLIGHT
END:VTIMEZONE

Note that the last RRULE has BYDAY=3SU, which is wrong, DST started on 8 March 2009, which should be 2SU.

Steps to reproduce:
1. set the system time to any day 9-14 March 2009 and fire up evolution
2. 
3. 


Actual results:
The calendar time is off by an hour

Expected results:
the calendar to be correct

Does this happen every time?


Other information:
The problem seems to be in libical/src/libical/icaltz-util.c

The problem is that the system zoneinfo gives the next date for daylight savings (correctly) as Sun Mar 14 03:00:00 2010 (which is still the second sunday in March).  However, the day of the month is 14 and dividing this by 7 gives 2, which r_pos tells us is the third sunday.

I think there's an off by one error here, the rule for calculating pos is

pos = r_pos [icaltime.day/7];

Which fails if the sunday is the last day of the week (the 14th in my case).  I think the calculation should be

pos = r_pos [(icaltime.day-1)/7];

so any sunday from the 1st to the 7th inclusive is in week 1 and so on
Comment 1 James Bottomley 2009-03-09 21:03:20 UTC
Created attachment 130352 [details] [review]
Fix for the problem

This is the patch I used in my version of evolution data server to fix the problem and bring the system time and evolution calendar time back into agreement
Comment 2 Matthew Barnes 2009-03-09 22:59:13 UTC
Evolution-Data-Server no longer uses its own copy of libical, and instead relies on upstream releases from http://sourceforge.net/projects/freeassociation/.

I'd encourage you to forward your findings to the Free Association project, as this seems to be a long standing issue in libical.  Good catch!

Closing as NOTGNOME since this is outside our scope.  But distro maintainers should take note.