Bug 232500 - [RHEL4] Calendar appointments are all one hour late after DST change
[RHEL4] Calendar appointments are all one hour late after DST change
Status: CLOSED WONTFIX
Product: Red Hat Enterprise Linux 4
Classification: Red Hat
Component: evolution-data-server (Show other bugs)
4.4
All Linux
low Severity medium
: ---
: ---
Assigned To: Matthew Barnes
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2007-03-15 15:26 EDT by Matt Seitz
Modified: 2008-02-04 00:37 EST (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2008-02-03 11:56:19 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)


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

  None (edit)
Description Matt Seitz 2007-03-15 15:26:40 EDT
+++ 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
correct.

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

-- Additional comment from rtlm10@gmail.com on 2007-03-13 19:05 EST --
Upstream bug:

http://bugzilla.gnome.org/show_bug.cgi?id=301363

-- Additional comment from mbarnes@redhat.com 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 rtlm10@gmail.com 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 mbarnes@redhat.com on 2007-03-14 11:24 EST --
The problem is not Exchange-specific.  Adjusting summary to collect dupes.

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

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

-- Additional comment from rtlm10@gmail.com 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 mbarnes@redhat.com on 2007-03-14 12:35 EST --
Good point.  I'll leave it open for the time being.

-- Additional comment from mjs@clemson.edu 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
steps):

(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 11:56:19 EST
Evolution 2.0.2 is only being updated for security issues.  Closing as WONTFIX.
Comment 2 Matt Seitz 2008-02-04 00:37:57 EST
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.