[Cosmo-dev] CosmoUI Timezone Proposal

[Matthew Eernisse]

Comments below.

Bobby Rullo wrote:
> You could pre-compile into Javascript  but not expand - just save the 
> work of doing the parsing on the client.  I bet the files would be 
> pretty small then.
> 
> When I say pre-compile into Javascript I mean the output could look 
> something like:
> 
> 
> registry.addTimezone(new cosmo.datetime.TimeZone('America/New_york" , 
> .....));
> registry.addTimezone(new cosmo.datetime.TimeZone('America/LosAngeles" , 
> .....));
> ...
> ...
> ...
> registry.addRule(new cosmo.datetime.Rule('US', 1945, ......))
> registry.addRule(new cosmo.datetime.Rule('US', 1945, ......))

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.

Adding executable JavaScript code would make the data files bigger than 
they already are. Think about it, you'd be adding all the method calls 
as well as the string-delimiting quotes for the params (even some that 
are ostensibly numbers can also be strings sometimes), as well as the 
commas. That's almost by definition going to be a larger file than just 
the data itself, right?

For reducing the file size -- one proposed solution was breaking the 
zones up into individual packages. The issue there is that the 
interdependencies in the data mean that the most straightforward way to 
get the information for a discrete TZ into a package is by pre-expanding 
the dates for the zone in an environment where the parser has access to 
all the data in one place.

You end up with a bunch of date expansions in your package that take up 
a lot of space, significantly reducing the intended benefit of breaking 
things up. As Adam mentioned, you might  be able to reduce file size 
there by reducing the date range supported. In that case you'd have to 
decide what a reasonable range of dates to support. 1950-2050 is what 
Ruby's TZInfo uses. Maybe 1980-2010 or something would be within a more 
tolerable file-size range, I don't know.

Given the expected size of the expanded dates in a pre-processed 
per-zone JSON package (maybe 5-8KB, extrapolated from the 11KB file size 
for the Los_Angeles file in TZInfo), and the 29KB size of the 
stripped-but-uncompressed Olson rules file for all of North America (and 
the ridiculously tiny size it can compress down to because it's just 
data and whitespace, 5.5KB), I'm still inclined to think just parsing 
Olson is the way to go.

It would take significantly less time and effort to do 
preprocessing/upkeep of the source data (basically it's just stripping 
comments and empty lines, raw files would still work too). And the 
download time for even the entire northamerica file would still be about 
the same as for fetching say three or four single TZ packages together 
(on initial app load, for example), especially when you add the overhead 
of the multiple connections to pull down each package.


Matthew