Earlier this year, users of Evolution again missed meetings because the meeting time was not displayed correctly. This blog post explains what the problem is and how it can be avoided in the future. It’s basically a summary of the corresponding GNOME Bugzilla entry #528902. I’m blogging about it now because I just committed fixes for this problem to the 2.22.x branch and trunk of Evolution – just in time for 2.22.3, the next stable release.
After the US changed the dates when they switch to and from summer saving time in 2007, programs and OS installations had to be updated to accomodate for this change. Since 2.12, Evolution uses the time zone information that is installed in the system so that Linux distributors only have to update one central package (usually called “tzdata”) when such changes happen. The US change wasn’t the only example; it just happened to be the one which affected most users.
However, this change in Evolution had no effect for meeting invitations. Each meeting invitation comes with its own definition of the corresponding time zone, and this is what Evolution uses – or rather, tried to use. Importing a new meeting invitation into a calendar which already contains an old time zone definition ignores the new time zone definition. The new meeting is then displayed using the old definition. Everyone who has used Evolution for a while is likely to be affected by this, because time zone definitions in the file calendar backend are never deleted.
The reason for this problem is that Evolution is designed so that for each time zone identifier, only one definition can be stored per calendar. If you have imported the 2006 definition of
GMT -0600 (Standard) / GMT -0500 (Daylight), then the updated 2007 definition of it will be ignored.
People (including a younger incarnation of myself… live and learn…) have argued that Microsoft should have embedded a revision string or year into their IDs to make them unique, but that is not required by the pertaining standards. Besides, Evolution 2.12 also no longer creates unique IDs. Recipients of meeting invitations simple have to handle conflicting time zone definitions, there’s no way around that.
Another problem with using the custom time zone definition that came with an event is that if that time zone changes later on, Evolution will continue to use the out-dated definition unless a new meeting invitation is sent. This also applies to old events that were created with Evolution <2.12: the current Evolution uses different IDs and therefore fails to use the more up-to-date system time zone information for those meetings.
Using the system time zones also potentially has the advantage of using more complete information about a time zone: the custom definitions included in meeting invitations are usually limited to just the transition rules for one year. If an event recurs in different years with different rules, then this is not sufficient. Unfortunately, Evolution only uses the rules for the two upcoming transitions even when the system time zone definition contains more rules. The effect is that a historic event in the US in 2006 is displayed using the updated rules for 2007, which leads to the wrong result for those weeks where the rules differ. Events very far in the future may also be affected.
Fixing the Problem
Redesigning the Evolution architecture was a scary thought because it would have been a very intrusive change which affects all calendar backends. Not suitable for a minor update in the stable release branch!
The approach taken instead for importing events consists of two steps:
- When importing an event, try to match the time zone to one of the system time zones. If that succeeds, then the meeting will automatically use the current set of rules and is displayed correctly even if those rules change. This mapping currently works for old Evolution events (regardless whether they are imported anew or already exist in a calendar) and meeting invitations sent by programs using the Olson database naming scheme with the location at the end (e.g.,
- The mapping does not yet work for Microsoft meeting invitations, to name just one example. Time zone identifiers are not standardized, so there needs to be a fallback: if mapping fails, the time zone definition is compared against an older definition with the same ID. If the definitions conflict, then the newer definition is renamed and stored under a new ID. This is visible in the Evolution GUI as a decimal number at the end of the the time zone name, like this:
GMT -0600 (Standard) / GMT -0500 (Daylight) 2.
In addition to importing events as described above, the time zone definition of existing events in a calendar is also updated on the fly to the current definition when displaying or exporting the event. Of course, this only works
Obviously, you need an updated Evolution which contains the patches. 2.22.3 and 2.24 will have them. But updating Evolution alone is not enough: meetings with custom time zone definitions which were imported earlier will continue to use the old definitions. You have to reimport all meeting invitations once more to update the time zone definition.
Remaining Work (Volunteers Wanted!)
Only the file and Exchange calendar backends have been adapted at this time. The same kind of problems will continue to occur with backends like the GroupWise one, unless someone who knows that backend steps up and fixes it. The change is simple; use the file backend diff as example.
The handling of system time zone information should be extended so that it uses the complete database and thus displays past and future events correctly. The Evolution developers plan to add that in some major future update (i.e., not 2.22.3).
Mapping of Microsoft time zone IDs would be useful, even though it is not strictly required thanks to the fallback. Microsoft uses two different ID formats: one includes a location and thus could be mapped if someone put together a mapping table. The other is composed of the two GMT offsets, as in the example above. Because different locations with different rules can end up with the same ID, the ID alone would not be enough to map back to the location. Instead of investing effort into analyzing the rules and inferring the original location from that, it is probably easier to simply rely on the fallback for conflict resolution.
SyncEvolution and other external programs
SyncEvolution takes care of importing time zone definitions correctly since 0.8 alpha 1, even when combined with an older Evolution release. This has to be done by each program which imports events using a combination of
e_cal_create_object(). Evolution itself has no chance to do the time zone mapping/renaming because it never has access to both the time zone definition and the corresponding event.