Bug 490218 - Evo2.12/ calendar is starting the 2009 DST one week later than it should in Americas
Evo2.12/ calendar is starting the 2009 DST one week later than it should in A...
Status: CLOSED ERRATA
Product: Red Hat Enterprise Linux 5
Classification: Red Hat
Component: evolution-data-server (Show other bugs)
5.3
All Linux
medium Severity medium
: rc
: ---
Assigned To: Milan Crha
desktop-bugs@redhat.com
:
: 488375 (view as bug list)
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2009-03-13 16:54 EDT by ritz
Modified: 2010-10-23 04:21 EDT (History)
4 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2009-09-02 05:14:39 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
patch based on upstream code (1.02 KB, patch)
2009-03-13 17:39 EDT, ritz
no flags Details | Diff
patch based on upstream code (1.41 KB, patch)
2009-03-16 12:27 EDT, ritz
no flags Details | Diff
little updated patch (2.32 KB, patch)
2009-04-01 09:33 EDT, Milan Crha
no flags Details | Diff


External Trackers
Tracker ID Priority Status Summary Last Updated
GNOME Desktop 574670 None None None Never

  None (edit)
Description ritz 2009-03-13 16:54:10 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:

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 17:39:32 EDT
Created attachment 335168 [details]
patch based on upstream code
Comment 3 ritz 2009-03-16 12:27:56 EDT
Created attachment 335369 [details]
patch based on upstream code

missed out a line. updated here
Comment 5 Milan Crha 2009-03-18 08:16:23 EDT
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 09:27:51 EDT
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 09:33:22 EDT
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 12:14:06 EDT
*** Bug 488375 has been marked as a duplicate of this bug. ***
Comment 20 errata-xmlrpc 2009-09-02 05:14:39 EDT
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

Note You need to log in before you can comment on or make changes to this bug.