Just before 2000 I found a funny security bug in AIX. You could schedule jobs to run at times and dates that did not exist. They would still run, but there was no way to see them in the list. It was a proud moment for me when IBM put my name on the patch release.

This week I have run into a much less serious but nonetheless annoying time bug in Microsoft’s Exchange.

Meetings that span timezones have started to move to a different spot on the calendar. For example, people sitting in California might notice their meetings are an hour later this week. Why?

When the meetings were created, they were in (GMT-08:00) Pacific Time (US & Canada); Tijuana

This week, however, Tijuana and Pacific Time are an hour apart. One would think that if the system that created the meeting was now operating in Pacific Time, the meeting would move to the new time. Not so, strangely. Instead the meeting moves to Tijuana time.

Microsoft gave some notice of this, but that does not change the fact that the system’s time zone was not accurately determined.

Calendar items that are created in a Mexican time zone are not detected by the tool
Mexico has not adopted the DST changes that were made in the United States. However, Mexico intersects with three of the five U.S. time zones. These time zones are the Pacific, the Mountain, and the Central time zones.

This results in new time zones with the same “GMT” modifier. For example, when the DST update is applied to Windows, the following “GMT -08:00” time zones exist:
• GMT -08:00 Pacific Time (US & Canada)
• GMT -08:00 Tijuana, Baja California
If a particular user is located in Tijuana, GMT -08:00 Tijuana, Baja California is now that user’s base time zone in Windows.

How would they know I am in the former rather than the latter? The patch they issued required a declaration of one or the other. After choosing, it should be pretty clear for what zone I want my meetings to be scheduled.