[Cosmo-dev] CosmoUI Timezone Proposal

[Matthew Eernisse]

Comment below.

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?

> Which is exactly why I'm proposing JSON and not executable Javascript.
> 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 
not right.

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?


Matthew