iCal, how can you do this to me?

After talking to Bruce, it seems that he has some of the same concerns for timezones that I do.

In a post, he pointed to something called VTIMEZONE. So, I went looking to see if perhaps there was another angle to this whole timezone storage mess.

VTIMEZONE is a data element attached to local times in iCal. It seems that when a recurring event is passed in iCal, it MUST have a VTIMEZONE component. So far so good. However, that VTIMEZONE record MUST specify information for DST! Bad iCal!

Of course, since this information is instantly incorrect, we end up with the problem we have had before. Even worse, because the information is fully specified in the message, developers are probably correct in assuming that they can't ignore the data and substitute their own information!

Personally, I feel this is a bug in iCal. I can see why it exists, to hand-wave around the timezone differences between Windows and OSX/Unix. At least they make a reference to the Olson (on which zoneinfo is based) database.

Developers, when implementing an iCal parser, use the VTIMEZONE value you receive as a way to determine the timezone, not as an actual descriptor. Based on the information in the VTIMEZONE component, find the timezone in your own TZ database and use that name when referring to the event. Never, ever, cache the definition.

Timezones and the FUTURE!

After reading Novell's report of the DST problem in GroupWise, I understand that a lot of these are software faults, and not problems with the OS or the timezone settings themselves.

When dealing with multiple timezones, what will a developer do? They’ll convert it to UTC for storage and comparison and then convert it back for display. This solution appears to completely remove the timezone from the problem and gives the developer a nice, sortable value to store.

Everything works fine until someone changes the start or end of DST. Immediately, all of the timestamps that were previously created for that period between the old and new start (and end) dates will be out by an hour.

If you’ve got a monthly/weekly recurring meeting it will be out by an hour into perpetuity for that 1 week every year.

The real fix is to store dates/times in the originator’s timezone and then convert them on the fly. It makes sorting a pain in the ass (time is no longer a single int!), but we’ve got CPU to burn so why not?

One final gotcha with that. You CANNOT store the originator's timezone as an offset! It needs to be a name used to retrieve the TZ information. If it is stored as an offset (I'm looking at you Oracle), you have the exact same problem. Using a name means that it becomes difficult to create an index across timestamps with mixed timezones, but the values will be correct!

The lesson to take away? You cannot convert a timestamp to UTC for storage if that timestamp is in the future.