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): evolution-2.22.3.1-1.fc9.i386 How reproducible: - cannot reproduce until next year - Actual results: Evolution calendar time is 1 hour ahead of real time. That renders all event-alerts and stuff useless. Expected results: Evolution should wait until next week. Additional info: 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: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=502839
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. http://bugzilla.gnome.org/show_bug.cgi?id=548268