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-server | Assignee: | Milan Crha <mcrha> | ||||||||
Status: | CLOSED ERRATA | QA Contact: | desktop-bugs <desktop-bugs> | ||||||||
Severity: | medium | Docs Contact: | |||||||||
Priority: | medium | ||||||||||
Version: | 5.3 | CC: | 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
ritz
2009-03-13 20:54:10 UTC
Created attachment 335168 [details]
patch based on upstream code
Created attachment 335369 [details]
patch based on upstream code
missed out a line. updated here
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? 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. 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.
*** Bug 488375 has been marked as a duplicate of this bug. *** 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 |