[Cosmo-dev] CosmoUI Timezone Proposal

[Bobby Rullo]

On Oct 26, 2006, at 11:38 AM, Matthew Eernisse wrote:

> 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. :)
>

Dude, I told you I was going to start this. :-0

> 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.

That's the plan. Initially, I am making it work the "simple" way -  
i.e. without any server side functionality. If I add stuff that  
depends on cosmo specific server-side functionality I will make sure  
to keep it segregated.

>
> 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.

Gotcha.

>
> - 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.)
>

Gotcha again.

> 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.
>

Yeah, I definitely want to pull in Etcetera and backward - especially  
backward as it has all the linkies.

> 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).
>

Good point - not sure what it means.... but noted :-)

> 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.
>

I don't think this is that important - it's a pretty easy thing to  
change either way. The most important thing for making this code Dojo  
friendly is making sure there is no dependencies on other cosmo  
stuff, and that I am doing.

By the way, if there are any dojo people listening: I really want to  
comment up my stuff the right way, so I can take advantage of the API  
tool but:

		a) I can't find docs on the API tool
		b) I can't find the API tool itself

Thanks!

Bobby

> 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
>
> _______________________________________________
> cosmo-dev mailing list
> cosmo-dev at lists.osafoundation.org
> http://lists.osafoundation.org/mailman/listinfo/cosmo-dev