Note: This is a beta release of Red Hat Bugzilla 5.0. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Also email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback here.
Bug 232500 - [RHEL4] Calendar appointments are all one hour late after DST change
Summary: [RHEL4] Calendar appointments are all one hour late after DST change
Alias: None
Product: Red Hat Enterprise Linux 4
Classification: Red Hat
Component: evolution-data-server
Version: 4.4
Hardware: All
OS: Linux
Target Milestone: ---
: ---
Assignee: Matthew Barnes
QA Contact:
Depends On:
TreeView+ depends on / blocked
Reported: 2007-03-15 19:26 UTC by Matt Seitz
Modified: 2008-02-04 05:37 UTC (History)
2 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2008-02-03 16:56:19 UTC
Target Upstream Version:

Attachments (Terms of Use)

System ID Priority Status Summary Last Updated
GNOME Bugzilla 301363 None None None Never

Description Matt Seitz 2007-03-15 19:26:40 UTC
+++ This bug was initially created as a clone of Bug #232113 +++

Description of problem:
All evolution calendar appointments are reporting as 1 hour later that they
actually occur.

They all seem to have timezone information such as 
GMT -0500 (Standard) / GMT -0400 (Daylight)

Any calendar appointments I have that use the America/New York timezone work
properly.  If I turn off timezone adjustment in my settings all of the
America/New York appointments are now incorrect and the ones from Exchange are

I am using the evolution-data-server-1.8.3-4.fc6 in updates-testing.

-- Additional comment from on 2007-03-13 19:05 EST --
Upstream bug:

-- Additional comment from on 2007-03-13 19:39 EST --
I'm aware of the problem and am already tracking it in the upstream bug you
referenced.   Closing this as UPSTREAM so that incoming details are centralized.

-- Additional comment from on 2007-03-13 21:32 EST --
Shouldn't this bug remain open until the upstream fix is packaged and deployed
to updates?

-- Additional comment from on 2007-03-14 11:24 EST --
The problem is not Exchange-specific.  Adjusting summary to collect dupes.

-- Additional comment from on 2007-03-14 11:25 EST --
Changing component to evolution-data-server.

-- Additional comment from on 2007-03-14 11:26 EST --
*** Bug 231865 has been marked as a duplicate of this bug. ***

-- Additional comment from on 2007-03-14 12:34 EST --
Matt it may be a good idea to reopen this bug so people will find it searching
bugzilla and not open duplicates.  The default search doesn't include closed bugs.

-- Additional comment from on 2007-03-14 12:35 EST --
Good point.  I'll leave it open for the time being.

-- Additional comment from on 2007-03-15 14:38 EST --
Has anyone actually read the upstream report comments?  Comments #44, #53, #55,
#57, #58 upstream seem to be the key.  Based on information there, what I did
was the following (actually, not quite, put I'm pretty sure these are the key

(1) Update evolution-data-server.  (Note that nothing in your local calendar
database changes as a result of this, so you can always back out if necessary.)

(2) Edit my local calendar database in
${HOME}/.evolution/calendar/local/system/calendar.ics. (Back it up first!) Look
for lines starting with "DTSTART;" and "DTEND;".  The following line is a
timestamp.  For every  DTSTART and DTEND with a corresponding timestamp in 2007,
replace the string "Olson_20011030_5" with "Olson_20070227_6".

(3) Restart Evo with "evolution --force-shutdown".

Then the reopen your calendar.  The appointments in the gap are now at the
correct time, and they display at the correct time in the clock applet's
calendar.  Also, the pushpin icon that appeared on each incorrect entry is gone.

Some things I didn't have to deal with:

- I'm not connecting to an exchange server yet, so I didn't need to fix shared
calendar entries.  Based on the comments, I think you need to accept them, then
edit your calendar file.

- I didn't have recurring appts made before 2007 that persist past the TZ
change.  I would guess that you can make the above change to those as long as
you don't care if they appear correcty in old years.  Otherwise, you probably
need to delete those and re-enter them.

Also, I am not sure if there is any "fix" that can be provided upstream.  The
changes I made above can be scripted, but they must be run by each Evo user. 
Providing the script seems to be the most that upstream could do.

Comment 1 Matthew Barnes 2008-02-03 16:56:19 UTC
Evolution 2.0.2 is only being updated for security issues.  Closing as WONTFIX.

Comment 2 Matt Seitz 2008-02-04 05:37:57 UTC
Wait nearly a year, then declare it's too late to fix the bug.  Not the kind 
of customer support I was hoping for.

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