Red Hat Bugzilla – Bug 467912
Evolution calendar ends DST one week too early
Last modified: 2008-11-13 05:40:23 EST
Description of problem:
Since this week, evolution thinks DST is over here in Berlin, which is definitely not the case.
Version-Release number of selected component (if applicable):
- cannot reproduce until next year -
Evolution calendar time is 1 hour ahead of real time. That renders all event-alerts and stuff useless.
Evolution should wait until next week.
see http://en.wikipedia.org/wiki/Daylight_saving_time_around_the_world#In_general for more informations.
Evolution uses system timezone data now, not its own.
Is your tzdata package up to date?
I assume: tzdata-2008h-1.fc9.noarch
Evolution calendar has a switch to choose if you want to calculate with DST. As a matter of fact evolution is 1hour behind now, while e.g. gnome app is not.
That bug also appeared on debian:
Happens on RHEL 5 too. Plain "date" is correct, but evolution calendar has got it wrong.
(In reply to comment #2)
> Evolution calendar has a switch to choose if you want to calculate with DST.
I was told that the option is (more or less) useless these days, but I do not know which state "works" better, either have it checked or unchecked can fix it.
There is also other possibility of the problem, each calendar source stores its own cache of timezones and in case it's present there, it uses it. When it has there stored incorrect timezone information, then it uses it too, instead of the (possible updated) system one. What is your calendar source type here? (like local/caldav/...) and was this the fresh install or some update from the previous version?
It was a local calendar, but as
a) DST is here now
b) that will happen after EOL of fedora 9
c) it's fixed in fedora 10
I think I'll close that bug (finally a positive result of fedoras short term support policy ;))
(In reply to comment #5)
> b) that will happen after EOL of fedora 9
> (finally a positive result of fedoras short term
> support policy ;))
True, but it did happen in RHEL 5 too.
I was directed to the upstream bug when asking the upstream developer of the other bug. Maybe it's related to this as well.