Red Hat Bugzilla – Bug 490218
Evo2.12/ calendar is starting the 2009 DST one week later than it should in Americas
Last modified: 2010-10-23 04:21:00 EDT
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:
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
The calendar time is off by an hour
the calendar to be correct
Does this happen every time?
copy pasted from - http://bugzilla.gnome.org/show_bug.cgi?id=574670
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:
PRODID:-//citadel.org//NONSGML Citadel calendar//EN
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.