[Cosmo-dev] CosmoUI Timezone Proposal
br at osafoundation.org
Thu Oct 26 11:52:19 PDT 2006
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.
> - 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.
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
a) I can't find docs on the API tool
b) I can't find the API tool itself
> That's all I have for now. I'm excited to see us making some real
> progress on this.
> Bobby Rullo wrote:
>> For the simple registry implementation (what mde has pretty much
>> 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.
>> cosmo-dev mailing list
>> cosmo-dev at lists.osafoundation.org
> cosmo-dev mailing list
> cosmo-dev at lists.osafoundation.org
More information about the cosmo-dev