Cosmo UI Timezone proposal

Standard Timezone Registry

We will be using the de-facto standard of timezone databases, the so-called "olson" or "zoneinfo" database.

The Server Side

---

On the server, the ical4j library already has incorporated within it the olson database converted to VTIMEZONES.

The Client Side

---

On the browser, mde has written some code^? which can parse olson files (not VTIMEZONEs, but original olson formatted files) and do the requisite math required to get offsets for a particular date in a particular timezone.

I propose we use this code as a starting point for client-side timezone support. First, we split up the code a bit - fetching timezones, parsing timezones and doing the requisite math are all orthrogonal, so I propose three new classes (forget packages, naming conventions for now):

• Timezone
  • Each instance of this class encapsulates all the logic (offset calculation for example) and data (observance rules and what not) necessary for a single olson Timezone
• TimezoneParser^?
  • A singleton which knows how to parse olson files, as well as individual olson timezones
• TimezoneRegistry^?
  • Another singleton - this one lets you look up a Timezone by it's id, and will resolved all the aliases in the "backward" file. Also caches timezones for subsequent lookups. Maybe provides a list of countries too, and then all the ID's for a particular country.

The reason for separating the parser and the registry is that I could see us creating a version of TimezoneRegistry^? which asks the server for a single timezone (so we don't have to parse all the timezones of all the continents) and the server looks it up and returns it. In such a case the same parser could be used. But we'd still want to retain the TimezoneRegistry^? which doesn't require a "smart" server - it just grabs the entire file(s) and parses all of it (them). This way we'd still be able to do unit testing without a running Java server.

Integration into existing client code

This should be really simple - we have the existing hooks already in place for calculating offsets and whatnot in CosmoDate^? as it is, but they just rely on the offsets provided by the server in the current Timezone object.

Here is the work required to get CosmoDate^? using the new timezone stuff:

1. Remove the faux timezone property from CosmoDate^? and replace with TimezoneId^? - just a string
2. Add static methods to CosmoDate^? to register an implementation of the TimezoneRegistry^? as a static property of the CosmoDate^? class (er prototype )
3. Change methods which used to use static offets and default browser offset to use offets obtained from timezones obtained from TimezoneRegistry^?
4. ...
5. Profit!

iCalendar <--> Cosmo UI model conversion

Right now there is a lot of hairy code in the converters to make sure that in the absence of timezones on the client, timezones are preserved on the server when converting back and forth. This stuff should be a lot easier now.

We can also get rid of all that code which calculates the offsets and passes back instead the timezoneId.