Torenware Networks

Some considerations to look at in comparing different solutions to handling time zones in Drupal:

• Correctness: People really like it when the time set for an event is correct for their time zone, especially when their time zone observes DST. Since there are literally hundreds of different zones with different rules for going between standard time and daylight savings time/summer time, this means allowing people to choose the right zone.
• Speed: Badly implemented time zone code can be very slow. Code size is important. Caching is usually necessary.
• Simplicity of UI: This one can be really hard, and it's very hard to do it right, since getting people to somehow pick the right zone out of 500 or more is pretty daunting. Anything you can do to reduce the number of choices is really valuable. Picking from a map can help. Also: if you already know the user's country, a simple JavaScript test can reduce the number of choices to only one or two. And even if you don't know the user's country: the same JavaScript test (offset from UTC in January, offset from UTC in July) will work on all versions of javaScript you'll ever see, and can reduce the number of meaningful choices to around 10 even in the worse of cases.
• Easy of Maintenance: Time zone data changes frequently; Olson of NIH comes up with updates of data at least once a year, and frequently more than once a year. Usually updates to any OS have to change the time zone tables. You want to make sure that you can update your libraries quickly, and with as little human intervention as possible. You also need to be able to debug them without going nuts.

There are certainly more than this, but this is a good basis for comparison.