ICU4J's TimeZone Ids Mapped To Windows Timezones

Posted by Dan on Mar 29, 2006 @ 5:37 PM

Ok, I've been working on trying to optimize some code recently. One of the huge bottlenecks in the application is the conversion of date/times to local user times. All date/times are stored in GMT in the database and are converted to user local when displayed.

We've been using a database table to do lookups/conversions of the date/times to make sure they display correctly depending on the user's region and whether or not they are in a daylight savings time. We're using custom data tables—which we have to maintain—not to mention it runs pretty slow on large recordsets.

In order to speed things up, I've been looking at using IBM's ICU4J's TimeZone class. Paul Hastings has written some nice little ColdFusion wrapper CFCs for this class. So far in my testing, under load the Java class performs about 10x more efficient that the db lookup code.

The problem I've run into is trying to figure out the mess that is the Olson Timezone DB (which is what is used in the Java classes) system of IDs. For each region there are a number of timezone (tz) ids that are valid—some have support Daylight Savings Time, some do not. There are over 550 tz ids, but only a fraction of them are actually unique.

I figured for a unique list of IDs, I might try seeing if I could map the Windows Timezone entries to the Olson DB format. Turns out, they already have a chart: zone_log.html

Categories: HTML/ColdFusion, Java


  • you might short cut some of the Olsen data's complexity by using the getAvailableIDs() method & pass it an iso 2 letter country code. that way you can at least present users w/stuff they might recognize. if you start chopping up the tz data, you'll eventually find people not recognizing their tz from the geographical areas that got the axe.

    also a matter of principal, if you have historic datetime data then i think those historic tz should apply.

    though you're right, it's a mess.
  • For our application, we're dealing with a pretty select range of dates and for all intents in purposes, we're dealing with US-based timezones.

    I figured I'd use the Windows TZ options as options on our site as it seems like a pretty decent list that should cover all the major areas (plus, all of current users are Windows-based and the majority of them always will be.)

    Using the Windows TZ just seems like the simplest solution. If I ever need it to be more complicated, I can expand the options.

Comments for this entry have been disabled.