[Cosmo-dev] CosmoUI Timezone Proposal

[Matthew Eernisse]

I just did a commit to get my source that Bobby's working with 
up-to-date. I did some stuff this past weekend, and didn't realize Bobby 
was going to get this into SVN so quickly. :)

Here are some notes:

1. Getting TZ data from the server

The simpler approach should be able to work with raw olson files -- and 
the more sophisticated approach seems like it will require some 
server-side fu to serve up the individually requested zones and rules.

Since we're hoping to share our code with the Dojo guys, we should make 
sure that base timezone functionality works either way. I'd like to 
propose that the pieces that depend on server-side functionality are 
kept distinct from the rest. Dojo is a supposed to be a purely 
client-side solution, and I think their approach of making it easy to 
optimize by compiling or pre-processing -- but not requiring it -- is a 
good one.

2. The "simple" approach

Even the simple (*cough*) approach of just sucking down a raw Olson file 
has a fair amount of ugliness about knowing which file you need to 
retrieve for a given timezone. There is a rough mapping of regions to 
files (e.g., 'Asia/' timezones are in the 'asia' file) -- but of course 
with some irritating caveats:

- The 'America/' zones are split between the 'northamerica' and 
'southamerica' files. So, requesting an unknown 'America/' timezone 
should result in the client pulling down the other file if they already 
have one loaded, and both if they have neither loaded.

- There are a bunch of exceptions. (Some examples -- there are a number 
of Russian 'Asia/' timezones in the 'europe' file. Also, most of the 
'Pacific/' zones are in the 'australasia' file, but there are a few 
(like 'Pacific/Honolulu') in the 'northamerica' and 'southamerica' files.)

I put the exceptions right there inline in the code. We might want to 
stick that into an external JSON file for maintainability, but then, 
hey, there's yet *another* file you have to pull down from the server.

- The GMT zone is in the 'etcetera' file, along with all the non-named 
zones like 'Etc/GMT+4'. We might need that, and the 'backward' file as 
well, to do anything really useful on the client. I guess we can package 
all that stuff together as part of the build (along with 
comment-stripping, maybe compressing), but it would be nice if whatever 
we put together doesn't require that, and can go grab those files (in 
addition to the default zone selected) as part of the initial setup.

3. Parsing time

Right now parseTimeString totally ignores the w/s/u/g/z letter 
appendation for DST leaps (the 'AT' field). This could make a big 
difference in when the time the leap happens for u/g/z (time is UTC).

4. Naming

This may not matter now, but I notice Bobby put this in the 'datetime' 
namespace in Cosmo. I'm hoping Dojo will want to use this, and it would 
likely end up in their 'date' module, so we might want to consider just 
calling it 'date' in our app too, so there will be less for us to change 
if Dojo does decide they want it.

That's all I have for now. I'm excited to see us making some real 
progress on this.


Matthew


Bobby Rullo wrote:
> For the simple registry implementation (what mde has pretty much done) 
> we just need to serve up the raw olson files, and Javascript parses them.
> 
> A more sophisticated approach might require that the server only send 
> down the rules needed to define a particular zone so  you could do 
> something like make a GET to 
> "http://osaf.us/cosmo/timezones/America\/New_York" and you get back all 
> the zone info for that zone.
> 
> Bobby
> 
> 
> _______________________________________________
> cosmo-dev mailing list
> cosmo-dev at lists.osafoundation.org
> http://lists.osafoundation.org/mailman/listinfo/cosmo-dev
>