On Wed, 16 Dec 2009, Michael G Schwern wrote:
Give me something to work with here. Some insight into what and why DateTime
is doing what its doing. Is there a reason that DST info has to be generated
linearly? Would it be difficult to hold off on generating time zone info
until its needed? Are there instructions somewhere for dealing with the
Olsen database? SOME sort of discussion about how to solve the problem
rather than the ways to paper over it.
I've thought about this a bit, and one solution I came up with was
something like this ...
When generating the time zone data, we know that after a certain point,
there is either one rule in effect (zone without DST or with permanent
DST), or two rules in fixed alternation.
Either way, we generate a subroutine that determines the current time zone
data (which is referred to as a "span" internally, as in a span of time
during which a specific rule is in effect).
For the one-rule zones, this is trivial. Just return the data for the last
rule.
For the two-rule zones, this should be calculable mathematically.
In both cases, we can simply not store the generated data, ever. The
generated files already include pre-calculated data for the next 10 years.
We could increase that to 20, and simply leave it at that.
-dave
/*============================================================
http://VegGuide.org http://blog.urth.org
Your guide to all that's veg House Absolute(ly Pointless)
============================================================*/
