Bug 490218

Summary: Evo2.12/ calendar is starting the 2009 DST one week later than it should in Americas
Product: Red Hat Enterprise Linux 5 Reporter: ritz <rkhadgar>
Component: evolution-data-serverAssignee: Milan Crha <mcrha>
Status: CLOSED ERRATA QA Contact: desktop-bugs <desktop-bugs>
Severity: medium Docs Contact:
Priority: medium    
Version: 5.3CC: llim, mcrha, rdoty, tao
Target Milestone: rc   
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2009-09-02 09:14:39 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Attachments:
Description Flags
patch based on upstream code
none
patch based on upstream code
none
little updated patch none

Description ritz 2009-03-13 20:54:10 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

Actual results:
The calendar time is off by an hour

Expected results:
the calendar to be correct

Does this happen every time?
always

Other information:
copy pasted from - http://bugzilla.gnome.org/show_bug.cgi?id=574670

Comment 1 ritz 2009-03-13 21:39:32 UTC
Created attachment 335168 [details]
patch based on upstream code

Comment 3 ritz 2009-03-16 16:27:56 UTC
Created attachment 335369 [details]
patch based on upstream code

missed out a line. updated here

Comment 5 Milan Crha 2009-03-18 12:16:23 UTC
This might be quite hard, I'm afraid. Main issue is the fact that libical doesn't hold the history of time changes, and that the time when they are changed can differ each year. As evolution is released twice a year, users get new definitions, but those old events are placed based on new defs, thus possibly incorrectly. It's known limitation, I think. Your timezone definition from the actual libical sources is this:

BEGIN:VCALENDAR
PRODID:-//citadel.org//NONSGML Citadel calendar//EN
VERSION:2.0
BEGIN:VTIMEZONE
TZID:/citadel.org/20070227_1/America/Chicago
X-LIC-LOCATION:America/Chicago
BEGIN:DAYLIGHT
TZOFFSETFROM:-0600
TZOFFSETTO:-0500
TZNAME:CDT
DTSTART:19700308T020000
RRULE:FREQ=YEARLY;BYMONTH=3;BYDAY=2SU
END:DAYLIGHT
BEGIN:STANDARD
TZOFFSETFROM:-0500
TZOFFSETTO:-0600
TZNAME:CST
DTSTART:19701101T020000
RRULE:FREQ=YEARLY;BYMONTH=11;BYDAY=1SU
END:STANDARD
END:VTIMEZONE
END:VCALENDAR

which is different from that yours above. Newer evo reads timezone information from system, but that doesn't make much difference, because when we ask for a timezone, then we do not specify a year, for which we want it (I do not know whether system tracks changes anyway).

The only thing we can do here, is to update timezone definitions in next package, and maybe include the above patch, but I'm afraid the patch itself could be incorrect, it depends on the result with newer definitions.

What do you think, ritz?

Comment 6 Milan Crha 2009-03-24 13:27:51 UTC
I just checked that evolution's libical uses /usr/share/zoneinfo/zone.tab, which is part of tzdata package, thus consider updating this in the next release of RHEL too? I do not know.

I arranged a test event at 10AM Chicago's winter time, recurring every day, for approximately 50 days, starting on March 3rd. I see two different behaving here, depending on an option Edit->Preferences->Calendar and Tasks, tab General, section Time, check "Adjust for daylight saving time".

When I have this check turned off, it shows all events before March 14th (inclusive) at 10AM, all after this date at 9AM. (That's one week off I suppose.)

When I turn on this check, it shows all events at 10AM for the whole period.

From Nick's description I guess he has that option turned off, am I right? Does it make any change, like for me, when you check/uncheck the option? I would also appreciate some test event, just to compare it with that mine, whether they are similar or different, because I do not see that "one hour ahead gone" for events after the April's first week.

Comment 12 Milan Crha 2009-04-01 13:33:22 UTC
Created attachment 337517 [details]
little updated patch

this is almost similar patch as that yours, I ony added two other changes in the libical, just to be sure. I tried this patch with America/Chicago and Europe/Prague, which both changes to summer time in a different week, and having the option "Adjust for daylight save time" checked I see no problem here, in both ways (have event in one timezone and evolution in the other, and vice versa), thus I'll use this in the package.

Your Gnome bug confused me, not talking about a diffence in a patch uploaded here and in that upstream bug.

Comment 19 Milan Crha 2009-06-16 16:14:06 UTC
*** Bug 488375 has been marked as a duplicate of this bug. ***

Comment 20 errata-xmlrpc 2009-09-02 09:14:39 UTC
An advisory has been issued which should help the problem
described in this bug report. This report is therefore being
closed with a resolution of ERRATA. For more information
on therefore solution and/or where to find the updated files,
please follow the link below. You may reopen this bug report
if the solution does not work for you.

http://rhn.redhat.com/errata/RHBA-2009-1259.html