Evolution displays wrong time after new dst

[Eugene Cormier]

Binary package hint: evolution

I'm in the timezone atlantic/halifax and I've updated my timezone info so that my system is working properly, but for some reason Evolution is reporting the time one hour early.....Evolution must have it's own time zone info (I think I read somewhere that it was a package "libical" but I couldn't seem to find that in edgy)

I assume this evolution timezone file should be updated (I'll keep searching for it in the mean time)

Eugene

Update: I've solved the problem on my system by going to the /usr/share/evolution-data-server-1.8/zoneinfo/ folder, then finding my timezone (which is "America/Halifax.ics") I open the file in gedit (using sudo) and change the line (after BEGIN:DAYLIGHT):
RRULE:FREQ=YEARLY;BYMONTH=4;BYDAY=1SU
to:
RRULE:FREQ=YEARLY;BYMONTH=3;BYDAY=2SU

save the file, and type into a console:
killall evolution-2.8
killall evolution-data-server-2.8

then restart evolution and it should now be the right time
(I have no idea if this fixes it forever or if its just for now....either way...it works for now

(I also think this bug belongs in the evolution-data-server bug list)

[Felix Kuehling (fxkuehl)]

I'm seeing the same with Eastern Time here. Even worse, calendar invitations I receive are off by one hour. For example a meeting that should have been from 4 to 5 PM was shown as 3 to 4 PM instead.

[Paul Smith (psmith-gnu)]

It's hard for me to believe that after all the hype this has been given, there are still no updates to solve these problems for either Edgy or (as far as I can tell) even for Dapper.

I realize it's the worst sort of drain bamage that Evo implements its own timezone management instead of just using the system defaults, but that's what we have and Ubuntu needs to work with it.

What's the holdup here folks?

[Eugene Cormier (eugene-cormier)]

Update: I've solved the problem on my system by going to
the /usr/share/evolution-data-server-1.8/zoneinfo/ folder, then finding
my timezone (which is "America/Halifax.ics") I open the file in gedit
(using sudo) and change the line (after BEGIN:DAYLIGHT):
RRULE:FREQ=YEARLY;BYMONTH=4;BYDAY=1SU
to:
RRULE:FREQ=YEARLY;BYMONTH=3;BYDAY=2SU

the save the file, and type into a console:
killall evolution-2.8
killall evolution-data-server-2.8

then restart evolution and it should now be the right time
(I have no idea if this fixes it forever or if its just for
now....either way...it works for now

--
****************************************
* Eugene Cormier *
* Acadia University *
* www.eugenecormier.com *
* <email address hidden> *
* DEN 152, [phone] *
* Classical Guitar, Music Technology *
* Preliminary Rudiments, Guitar Class, *
* Guitar Ensemble *
****************************************

[skippy (skippy)]

See GNOME bug 417461:
http://bugzilla.gnome.org/show_bug.cgi?id=417461

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

The Ubuntu Evolution maintainers need to push out the fix.

[Daniel Robitaille (robitaille)]

I can confirm this on Dapper using the Pacific/Vancouver timezone.

[Sebastien Bacher (seb128)]

fixed to feisty with GNOME 2.18.0

[Sebastien Bacher (seb128)]

The patch is a Fedora FC6 update one

[Sebastien Bacher (seb128)]

The patch is a Fedora FC5 update one

[M. Walter (m.walter)]

I am not familiar with how Evolution sets and displays its times, but several things were "broken" by the DST. Among them, alarms are also one hour off. In addition, if you hold the mouse over an appointment, the time shown in the pop-up is also 1 hour off. The fix to the *.ics files listed above does not fix the two problems I just mentioned. Glad to see that initial problems are being addressed through an update. Hopefully the proposed changes will also fix these issues?

[NoOp (glgxg)]

I can confirm that this appears to have been fixed in Feisty.
Feisty Herd5
Kernel: 2.6.20-11-generic
GNOME: 2.18.0(Ubuntu 2007-03-13)

I can also confirm that it's still broken in Dapper.

Thought about copying the /usr/share/evolution-data-server-1.8/zoneinfo/ files over from Feisty, but I suspect that wouldn't be a real 'fix' after looking at Sebastien Bacher's proposed change file.

[Martin Pitt (pitti)]

Patches look fair enough, please upload immediately.

[Sebastien Bacher (seb128)]

uploaded to dapper-proposed and edgy-proposed

[Martin Pitt (pitti)]

Accepted into dapper-proposed, please go ahead with QA testing. Please also ponder cutting down the 7 days waiting period for this one.

[Martin Pitt (pitti)]

Accepted into edgy-proposed, please go ahead with QA testing. Please also ponder cutting down the 7 days waiting period for this one.

[Romulus (launchpad-keithtyler)]

Eugene's fix (alone) will only solve the related problems until October, or until this is fixed in stable.

For long-term fix, just in case, in the TZ file, under BEGIN:STANDARD, also change:

RRULE:FREQ=YEARLY;BYMONTH=10;BYDAY=-1SU
to
RRULE:FREQ=YEARLY;BYMONTH=11;BYDAY=1SU

[Michael Vogt (mvo)]

Dapper verification is done, I checked that in US/New_York timezone and date 12.03.2007 date -R reports daylight time. But the evolution calendar is off by one hour (the thin red line). Once the update is in and the data-server is restarted, this is fixed.

We should not embargo this update for 7 days given the urgency of the fix. It should be uploaded now (its in -proposed since monday).

[Michael Vogt (mvo)]

Edgy verfication is done now too. The same test was done as for dapper.

[Sebastien Bacher (seb128)]

uploaded to dapper-updates and edgy-updates now

[Martin Pitt (pitti)]

Accepted into edgy-updates.

[NoOp (glgxg)]

I can confirm that today's updates corrected the problem on my Dapper system.

Thanks!

[Joey Stanford (joey)]

Adding my name to the list of users experiencing this problem. Thanks Martin for the updates.

[Joey Stanford (joey)]

forgot to mention, this also impacts FEISTY.

[Sebastien Bacher (seb128)]

the bug has already been fixed to feisty with GNOME 2.18.0

[Joey Stanford (joey)]

Seb,

It's not fixed in Feisty, at least not for me. Evolution still is 1 hour off of the correct time when scheduling meetings in UTC. It doesn't matter if I have the daylight savings time box checked or not.

Joey

[Jason Harley (jharley)]

I'm running a fully patched Dapper and after installing the flurry of evolution updates yesterday (killing processes and doing a full reboot) all of my appointments are still an hour off (I have a reoccurring appointment that is the proper time on March 5th and the wrong time on March 12th).

Have I missed something? I tried resetting my timezone in the Preferences as well.

[Sebastien Bacher (seb128)]

what timezones you guys are using?

[Jason Harley (jharley)]

Sorry, I left that out... :\

I've tried America/Montreal and America/Detroit -- both with no luck. America/Montreal is my preferred.

[Joey Stanford (joey)]

Seb: Americas/Denver

Running 2.10.0 on Linux c14n 2.6.20-13-generic #2 SMP Sun Mar 25 00:21:25 UTC 2007 i686 GNU/Linux

[Daniel Robitaille (robitaille)]

What I get in Dapper is that this patch correctly fixed the incorrect time inside Evolution (for Pacific/Vancouver time zone). So If I go in Evolution-Calendars, the red line indicating the current time is now correct (it wasn't before). As for individual appointment, they are now MOSTLY correct. I have some old reccurring weekly appointments that are still off by an hour for the period between March 11 and the end of March. But they are correct for the weeks before March 11, and for the weeks starting in April.

But this problem with reccuring appointments doesn't happen for newly-created appointment; so it seems to only affect old appointments that were created before the switch to DST and/or before this round of evolution patching.

[Joey Stanford (joey)]

Here is my tz from calendar.ics.

BEGIN:VTIMEZONE
X-LIC-LOCATION:America/Denver
TZID:/softwarestudio.org/Olson_20011030_5/America/Denver
BEGIN:STANDARD
DTSTART:19701025T020000
TZNAME:MST
TZOFFSETFROM:-0600
TZOFFSETTO:-0700
RRULE:FREQ=YEARLY;INTERVAL=1;BYDAY=-1SU;BYMONTH=10
END:STANDARD
BEGIN:DAYLIGHT
DTSTART:19700405T020000
TZNAME:MDT
TZOFFSETFROM:-0700
TZOFFSETTO:-0600
RRULE:FREQ=YEARLY;INTERVAL=1;BYDAY=1SU;BYMONTH=4
END:DAYLIGHT
END:VTIMEZONE

[NoOp (glgxg)]

On 03/27/2007 05:14 PM, Joey Stanford wrote:
> Here is my tz from calendar.ics.
>
> BEGIN:VTIMEZONE
> X-LIC-LOCATION:America/Denver
> TZID:/softwarestudio.org/Olson_20011030_5/America/Denver
> BEGIN:STANDARD
> DTSTART:19701025T020000
> TZNAME:MST
> TZOFFSETFROM:-0600
> TZOFFSETTO:-0700
> RRULE:FREQ=YEARLY;INTERVAL=1;BYDAY=-1SU;BYMONTH=10
> END:STANDARD
> BEGIN:DAYLIGHT
> DTSTART:19700405T020000
> TZNAME:MDT
> TZOFFSETFROM:-0700
> TZOFFSETTO:-0600
> RRULE:FREQ=YEARLY;INTERVAL=1;BYDAY=1SU;BYMONTH=4
> END:DAYLIGHT
> END:VTIMEZONE
>

Then you didn't get updated. Here is the updated America/Denver (March
26 version - Dapper):

BEGIN:VCALENDAR
PRODID:-//Ximian//NONSGML Evolution Olson-VTIMEZONE Converter//EN
VERSION:2.0
BEGIN:VTIMEZONE
TZID:/softwarestudio.org/Olson_20070227_6/America/Denver
X-LIC-LOCATION:America/Denver
BEGIN:DAYLIGHT
TZOFFSETFROM:-0700
TZOFFSETTO:-0600
TZNAME:MDT
DTSTART:19700308T020000
RRULE:FREQ=YEARLY;BYMONTH=3;BYDAY=2SU
END:DAYLIGHT
BEGIN:STANDARD
TZOFFSETFROM:-0600
TZOFFSETTO:-0700
TZNAME:MST
DTSTART:19701101T020000
RRULE:FREQ=YEARLY;BYMONTH=11;BYDAY=1SU
END:STANDARD
END:VTIMEZONE
END:VCALENDAR

Notice the:
TZID:/softwarestudio.org/Olson_20011030_5/America/Denver
vs
TZID:/softwarestudio.org/Olson_20070227_6/America/Denver
difference.

All of your files in /usr/share/evolution-data-server-1.6 should be
dated 26 March 2007.

[NoOp (glgxg)]

On 03/27/2007 05:14 PM, Joey Stanford wrote:
> > Here is my tz from calendar.ics.
> >
> > BEGIN:VTIMEZONE
> > X-LIC-LOCATION:America/Denver
> > TZID:/softwarestudio.org/Olson_20011030_5/America/Denver
> > BEGIN:STANDARD
> > DTSTART:19701025T020000
> > TZNAME:MST
> > TZOFFSETFROM:-0600
> > TZOFFSETTO:-0700
> > RRULE:FREQ=YEARLY;INTERVAL=1;BYDAY=-1SU;BYMONTH=10
> > END:STANDARD
> > BEGIN:DAYLIGHT
> > DTSTART:19700405T020000
> > TZNAME:MDT
> > TZOFFSETFROM:-0700
> > TZOFFSETTO:-0600
> > RRULE:FREQ=YEARLY;INTERVAL=1;BYDAY=1SU;BYMONTH=4
> > END:DAYLIGHT
> > END:VTIMEZONE
> >

Then you didn't get updated. Here is the updated America/Denver (March 26 2007 version - Dapper):

BEGIN:VCALENDAR
PRODID:-//Ximian//NONSGML Evolution Olson-VTIMEZONE Converter//EN
VERSION:2.0
BEGIN:VTIMEZONE
TZID:/softwarestudio.org/Olson_20070227_6/America/Denver
X-LIC-LOCATION:America/Denver
BEGIN:DAYLIGHT
TZOFFSETFROM:-0700
TZOFFSETTO:-0600
TZNAME:MDT
DTSTART:19700308T020000
RRULE:FREQ=YEARLY;BYMONTH=3;BYDAY=2SU
END:DAYLIGHT
BEGIN:STANDARD
TZOFFSETFROM:-0600
TZOFFSETTO:-0700
TZNAME:MST
DTSTART:19701101T020000
RRULE:FREQ=YEARLY;BYMONTH=11;BYDAY=1SU
END:STANDARD
END:VTIMEZONE
END:VCALENDAR

Notice the:
TZID:/softwarestudio.org/Olson_20011030_5/America/Denver
vs
TZID:/softwarestudio.org/Olson_20070227_6/America/Denver
difference.

All of your files in /usr/share/evolution-data-server-1.6 should be
dated 26 March 2007.

[Joey Stanford (joey)]

I just did a grep and an amazing amount of them are dated 20011030. I'm a fresh, clean, install of Feisty.

[Joey Stanford (joey)]

Interesting...I just edited Denver.ics and it is correct but my evolution calendar.ics which I pulled that tzinfo from, is not.

[ichhaankur (n-arju-lx)]

I saw a very similar problem. When I edit the task, the time is entered at 11:00am, let's say. However, on evolution calender view, it shows the time to be one hour earlier at 10:00 am. (See attachment.) Not hard to guess, the alarms are being rung at the wrong time.