[Cosmo-dev] CosmoUI Timezone Proposal
mde at osafoundation.org
Tue Oct 31 10:47:53 PST 2006
Adam L. Peller wrote:
>> That would indeed speed up parsing, but I'm pretty sure parsing time
>> isn't the speed limiter. I'm sure mileage will vary with
>> processor/memory, but overall, parsing time is going to be miniscule
>> compared to the download time for the data.
> Agreed. When it comes to performance, IMO, it's more about the size
> of the data and the size of the code required to do the processing
> (also data over the wire). With JSON, the code required to read the
> files approaches zero. Less data is good for network performance, but
> less code is a good thing overall.
Right, less code overall is the right aim. The initial implementation
just split all the raw data into plain Arrays, so it was about 40 lines
of code total to get the TZ data into memory. JSONizing the data so all
we have to do is 'eval' would cut the need for that to nil, but I wonder
how much would JSONizing add to the source data files? Would it be more
than what's in the 40 lines of code?
> JSON is just a data structure, designed to work with your code, as if
> you'd done all the registry stuff. If multiple files need to be
> merged, a mix-in approach can sometimes do the trick.
Okay, some of the disconnect here may be in use of the word 'parse.'
There are actually two separate operations going on here.
The initial data files have to be parsed into some structure in memory.
The initial implemenation of this just uses Arrays and raw data -- no
objects with named properties. This parsing is low-cost no matter
whether you use regex/split or JSON/eval.
The other 'parsing' (don't even know if that's the right word) is the
real heavy lifting. It's the part where the code pokes around in those
data structures in memory to figure out what the offset should be for a
given TZ/date combination. (That's what you'd be doing server-side if
you pre-processed the data for each individual TZ -- calcluating those
offset changes for each year, and putting the list of those changes into
some sort of consumable data structure.)
The original code just uses raw Array positions to referrence the data
for the calculation piece. It's less readable than named properties of
course, but given how simple the Olson format is, it's pretty easy to
see what's what if you have an example of the format to look at. (Er,
and I guess comments would help too.)
The code I wrote does those calculations on the fly, but it sounds like
Bobby is working on a different approach. I'd like to hear a little more
detail about how he's implementing that.
> Actually, I was being more radical than that... I was thinking of an
> *optional* light version of the code which dropped historical
> information entirely (both the data and the logic that goes with it).
> I know this would result in inaccurate past (or future) dates, but I'm
> guessing it's good enough 90% of the time? At least, if you're not in
> a multi-user scheduling application :-)
Sure, you could either hard-code the offsets (of course then you'd get
bugs filed like 'getTimezone doesn't support daylight savings time' :)),
or assume the DST leap never changes. That might be something you could
extract from the full version.
You'd also have to caveat the limiations somewhere very clearly, because
you will have users scratching their heads when they hit the 10% that's
And this could just be my bias working with calendaring, but it does
kind of seem like you either do timezones, or you don't. Once you start
trying to do anything that's timezone-aware, it's that slippery slope
down to Olson. :)
> Any transformations could be automated, and I was hoping the Dojo
> build system would help us out here (big hand-wave, but it ought to be
> something that can be optimized somehow)
Looks like the doc parser does something similar with creating JSON data
for consumption -- if you're talking about pre-processing/expanding the
dates. However, since expanded dates for a couple of zones take up as
much space as the rules themselves, doesn't it make sense just to let
the browser deal with the rules directly?
More information about the cosmo-dev