Timezone Issues in Scooby the Cosmo UI

Current Status

In context of what the browser gives you out of the box, there is no real timezone support. You can only figure out for a given date what the offset from GMT is for your computer's system time and a three letter timezone code. Offset alone is not enough for us to determine which timezone we are in (ex - Rio De Janeiro and New York sometimes have the same offset. Other times they could be 1 hour or two hours apart!) but it is enough to place events with timezones properly on the UI, as long as each date we get back from the server has offset from GMT with it.

Floating events work fine.

What we are doing now

Early on mde and I made the decision that it was important right from the beginning to have enough timezone support to at least properly display events from other sources like Chandler and iCal which have timezones even if we wouldn't be able to create events with timezones or change the timezone within Scooby (as it was named then.) In other words, we wanted events in NY that start at 12pm to show in the 9am slot on the ui for West coast users.

Since the browser will provide the local offset from GMT for any particular date, and we have the event start-time and end-time of an event in its timezone, we only need the timezone offset for that start-date in the event's timezone to figure out where it is in relationship.

The hard way (and the direction we may need to take eventually) to do that is to serialize the entire Timezone for an event, give it to the browser, have the browser parse it, and figure out the offset for that date (or the date in GMT.) The reason that this is hard (or perceived as hard ) is because timezones can be rather complex, with lots of recurrence rules, exceptions to recurrence rules, etc. Also, timezones can be really large, and we wanted to avoid putting these on the wire.

The easy way to do things was to simply let the server calculate the GMT offset for each start-date and end-date and pass it to the client. This is what we ended up doing.

The upshot of this is that we can display events with timezones properly.

What we can't do

What we cannot do yet is create new events with timezones, or change the timezone of an event.

Uh, why not? (or, what do we need to get there)

To create an event with a timezone the user would either need to choose the timezone themselves or to have a default timezone for that user. If the user were to choose a timezone, they would have to pick from some list of timezones somehow, which means that there would have to be some representation of timezones on the client, and a repository of timezones on the server. If the user were to have a default timezone, we would have to figure out the default timezone for that user, or have them choose from a repository of timezones on the server.

When you create an event you can do so by either double clicking on the canvas or by manually entering the information in on the detail side. If you create the event by double clicking on the canvas, the client must calculate the time start time of the event. If the event to be created has a timezone, you would need to know what the date is for the UTC represented by the pixel position. You cannot simply use a single value for offset - offsets change throughout the year to due Daylight savings and other observances. Therefore the client would need to either have logic to fully parse out and calcualte useing timezones, or ask the server for more info. Similarly, if you create by entering the info in the detail panel, you need to calculate where on the canvas to place the event which again requires knowing the GMT offset (or UTC equiv time) for that particular date.

The issues brought about can be summarized as:

1. Server-side repository of "standard" Timezones
2. Client-side lookup of TimeZones^?
3. Client-side representation

Technical Discussion of Issues

Server-side repository of "standard" timezones

This seems relatively straightforward. We would need to

• find a library of timezones like Zoneinfo
• commit it into the codebase, or make it a maven dependency
• either import it into the RDBMS or cache them in memory or just leave them on disk or some combination of the three
• perhaps have some config file which lets the sysadmin choose the default timezone for users
• have service methods that let you look up these "standard" timezones

Client-side lookup of timeones

Once we have a library of standard timezones stored on the server, it seems like it would be a relatively easy thing to simply fetch a timezone by its ID, like "America/NY". The problem is that we expect to have Cosmo populated with events from many different sources (ical, chandler, thunderbird, outlook, etc) and each one uses a different library of timezones. In CalDAV world and in the way that Cosmo stores data, timezones are stored with events. So if there are 10 events with an "America/NY" timezone, each one has a copy of the timezone. Add to this the fact that TZID is not globally unique means that you cannot simply refer to a timezone in the CosmoUI^? event model by an ID - how would we know if the id is refererring to one of the standard timezones (ones in the repository) or one that has the same TZID that is stored with the event.

Of course, we could do as CalDAV does - for every event that has a timezone, download its VTIMEZONE as well. The problem with this is that it's sort of waste of bandwidth - VTIMEZONE's can be big and it seems wasteful to download the same one a bunch of times for every event.

Or we could add something to the Cosmo server data model, which tells us whether the timezone on an event is one of our standard timezones or a "custom" one.

Right now, I'm sort of leaning towards just downloading the timezone for every event - I think the "custom" timezone thing will be the norm for many people since we (or at least I) tend to get events from a pretty wide variety of sources and so every event will have a "custom" timezones.

Client-side representation

As far as the representation of timezones on the client here are the main issues:

1. Degree of Richness of the model
   • How much of the semantics of a VTIMEZONE do we need on the client side? Choices include
     • None - we just send back a reference to the timezone, and go back to the server whenever we need TZ calculations
     • All/Most - we do enough stuff to calculate offsets for given points in time, UTC equivalents, etc.
     • Wee bit - send back some object which maybe just has the the offset switches for a particular block of time
2. Object Model
   • if we go with a rich timezone object how do we model it on the client side?
     • we could send back the whole VTIMEZONE stream.
     • maybe there is an xcalendar version?
     • we could make our own object model for timezones

My current inclination is to parse realife honest to goodness VTIMEZONEs - If and only if there is someone (like dojo) who has done the work of parsing it out and writing the calculations. Otherwise....not sure.

-- BobbyRullo - 11 Sep 2006