Bug 232113

Upstream bug:

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

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.

Shouldn't this bug remain open until the upstream fix is packaged and deployed
to updates?

The problem is not Exchange-specific.  Adjusting summary to collect dupes.

Changing component to evolution-data-server.

*** Bug 231865 has been marked as a duplicate of this bug. ***

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.

Good point.  I'll leave it open for the time being.

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.

(In reply to comment #9)
> 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):

Oh, yes I'm following it.  Entertaining is probably the word. . .

> (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".

Ouch

> - 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.

You can't edit your calendar file since its stored on the Exchange server.  They
only thing you can do is edit the cache files (if you're keeping an offline
copy)  When you reconnect the online version wins and you're back to square one.

> 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.

This seems like a parsing problem to me.  Especially since the meetings display
properly in the original email.

Thanks for keeping track of this stuff.

(In reply to comment #10)
> (In reply to comment #9)

> > - 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.
> 
> You can't edit your calendar file since its stored on the Exchange server.  They
> only thing you can do is edit the cache files (if you're keeping an offline
> copy)  When you reconnect the online version wins and you're back to square one.

Actually, see comments #58 and #63 from upstream.  After rereading, I see the
solution for this issue is apparently to modify the specs of the TZ designator
that the server specifies.  That has the drawback that appointments in the DST
gaps for previous years will be wrong, but one would hope that's a minor issue
for most folks.

That's another MS "defective by design" thing.  The Exchange patch apparently
just updated the specs on the old designator, rather than creating a new one...

> 
> > 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.
> 
> This seems like a parsing problem to me.  Especially since the meetings display
> properly in the original email.
> 
> Thanks for keeping track of this stuff.

We're moving to Exchange here, so I'm kind of attuned to it now, plus it's
really annoying to be late for all my appts 8^).

Thanks for comment #9.

Just for others that may be lurking -

The calendar file I had to update was
~/.evolution/calendar/local/1170728290.14799.0@hostname_xxxx/calendar.ics (since
I have created a different mailbox than the default one in Evolution).

So, using the instructions in comment #9, I did the following:

1) quit Evolution; backup .evolution directory
2) edit ~/.evolution/calendar/local/1170728290.14799.0@hostname/calendar.ics
   - I searched and replaced all instances of 'Olson_20011030_5' with
'Olson_20070227_6' (I'm not saying that EVERYONE should search and replace all
instances, but that is how it worked in my case.  I don't have a lot of
appointments in my calendar, however.)
3) evolution --force-shutdown
4) start Evolution

Those steps fixed everything EXCEPT a recurring meeting that was sent out by an
Outlook user.  To correct that, I did the following:

1) quit Evolution; backup .evolution directory
2) edit ~/.evolution/calendar/local/1170728290.14799.0@hostname/calendar.ics
   - I located the "DTSTART;" and "DTEND;" lines for the meeting that had the
wrong time
   - I replaced the text "TZID=Mountain Time (US & Canada)" with the text
"TZID=/softwarestudio.org/Olson_20070227_6/America/Denver" on those two lines
3) evolution --force-shutdown
4) start Evolution

This fixed the bad meeting time.

Finally, I also have my Google Calendar available in Evolution ... an
appointment on March 13 shows the right time, but it also shows the pushpin
icon.  I could probably go into the cache.xml file at
~/.evolution/cache/calendar/webcal___www.google.com_calendar_ical_user.ics
and figure out how to fix it, but I'm guessing that it would just get
overwritten at the next sync with Google Calendar.  Or maybe I should delete the
file and let Evolution resync.  In any case, for me, it isn't worth the bother.


Maybe this will help someone ... this is a rather unfortunate bug, and I'm
surprised there isn't more screaming on the fedora list.

*** Bug 231867 has been marked as a duplicate of this bug. ***

I tried the search and replace but it didn't work for recurring appointments
that started before the time zone change and ended after.

What kills me about this is before the evolution-data-server upgrade, evolution
itself (not the clock applet) handled this time zone change perfectly. Why can't
we revert to that behaviour?

(In reply to comment #14)
> I tried the search and replace but it didn't work for recurring appointments
> that started before the time zone change and ended after.

It did for me.  If your recurring appts started before 2007, though, you'll have
to find them by creation date.  Andf they crossed a DST boundary in 2006,
they'll be wrong in 2006 if you fix them in 2007.  I'm not sure if there's a fix
for that other than to cancel then starting before the change and recreate them.

I don't know if it's been done yet, but there's supposed to be a change in
Evo/evo-data-server to use the system DST info.

> 
> What kills me about this is before the evolution-data-server upgrade, evolution
> itself (not the clock applet) handled this time zone change perfectly. Why can't
> we revert to that behaviour?

Because it didn't really work before.  The clock applet is proof that DST was
not done correctly in evo-data-server--no telling what other apps that rely on
evo-data-server might be affected.  But if you don't like the way it is now, you
can back out the evo-data-server update and you'll have the old behavior.  Hold
off updating for another two weeks, and then you shouldn't care.

> It did for me.  If your recurring appts started before 2007, though, you'll have
> to find them by creation date.

No, they started around the start of 2007 but were still wrong.

> But if you don't like the way it is now, you
> can back out the evo-data-server update and you'll have the old behavior.  Hold
> off updating for another two weeks, and then you shouldn't care.

Yeah, I've downgraded for the moment. But it seemed to me that the times were
wrong even next month with the update - why should holding off for two weeks
help then? Is there a better fix on the way?

(In reply to comment #16)
> Yeah, I've downgraded for the moment. But it seemed to me that the times were
> wrong even next month with the update - why should holding off for two weeks
> help then? Is there a better fix on the way?

Things should be fine after the *old* DST change date of April 1 (until the next
gap in October...).  (I just checked and times are correct after April 1 with my
old calendar.ics file.)

If you read the upstream discussion, it's hard to tell exactly where things are,
but they appear to be working on it.

Ah, okay, good to know things will be okay in a few weeks then, thanks for the
info. (and I imagine by October they'll have figured something out, hopefully)

Here's a link to a tool to make existing Evolution appointments use the latest
timezones.  It was written by one of the upstream Evolution authors.  Make sure
you've updated your evolution-data-server package to include the latest daylight
savings time changes before running this tool.

For FC6, the DST changes were published in evolution-data-server-1.8.3-3.fc6.

http://chenthill.wordpress.com/2007/03/16/migrating-appointments-from-old-timezone-to-updated-ones/

Well, now that it's April I updated and this months' appointments are fine (in
evo and the calendar applet) even though they're repeating from a few months
ago. Last months' appointments are still off by an hour, which is a minor
annoyance but not really important.

(In reply to comment #20)
> Well, now that it's April I updated and this months' appointments are fine (in
> evo and the calendar applet) even though they're repeating from a few months
> ago. Last months' appointments are still off by an hour, which is a minor
> annoyance but not really important.

And that's your only problem from now till the last week in October.  Hopefully,
things will have settled down and patches will have been issued by then...

(In reply to comment #21)
> And that's your only problem from now till the last week in October.  Hopefully,
> things will have settled down and patches will have been issued by then...

Probably better to just fix any existing appointments you have for that week.

(In reply to comment #22)
> (In reply to comment #21)
> > And that's your only problem from now till the last week in October.  Hopefully,
> > things will have settled down and patches will have been issued by then...
> 
> Probably better to just fix any existing appointments you have for that week.

Again, AIUI, the issue is Exchange calendars. Unless and until MS properly
patches Exchange's DST data, every connection to Exchange will overwrite any
local corrections.  If Exchange isn't patched in a way compatible with Evo, then
Evo or evo-data-server or something will have to fix the buggy Exchange entries,
or users will be left to fix them for every DST transition every time they are
updated from the server.

(In reply to comment #23)
> Again, AIUI, the issue is Exchange calendars. Unless and until MS properly
> patches Exchange's DST data, every connection to Exchange will overwrite any
> local corrections.  If Exchange isn't patched in a way compatible with Evo, then
> Evo or evo-data-server or something will have to fix the buggy Exchange entries,
> or users will be left to fix them for every DST transition every time they are
> updated from the server.

It may not be a bug in Evo, but its going to be up to the Evo developers to fix
it.  I'm pretty sure this was deliberately fixed improperly to mess with 3rd
party apps connected to the Exchange servers.  

As much as it sucks, stating the problem is Microsoft's and washing our hands of
the matter isn't going to work.  We need to handle the incorrect meeting notices
they send out.  :-(

BTW, October is almost upon us -- is this fixed?

Evolution-Data-Server now uses system timezone information instead of its own,
but any appointments created before the user updated E-D-S with the new U.S. DST
changes will still be an hour off after we adjust our clocks in October. 
There's just no easy way around this since timezone information gets embedded
directly into iCalendar events at creation-time.  Users will need to adjust any
such appointments themselves.

The issue is "fixed" insofar as E-D-S now has correct U.S. DST information.

Closing this since there's not really anything more I can do about it.

Setting the resolution to CURRENTRELEASE since the Fedora 8 E-D-S uses
system-wide timezone information instead of its own.