Stephen Turner wrote:

...

-----Original Message----- Date: Wed, 10 Jan 2007 08:12:18 -0700 From: Jeff Garland <jeff@crystalclearsoftware.com>

Yes, sorry I was off the net on holiday for an extended period :-) Finally getting caught up now...

Thanks!

...

I would recommend that this be created as an alternative tz_database class -- something like 'historic timezone database'. My experience is that must applications don't need the historic data and hence only really care about loading up the current set of rules.

I'm sure that's true for many users. But I also wonder how many users there are who do care but haven't had a problem until now because they're in countries where the rules haven't changed in recent years, so it's just worked.

Good point -- the US change is certainly an unusual event -- hopefully others will chime in on this.

But let me put it the other way round. If a historical database were available, why would anyone choose to still use the existing method?

Memory usage would, I think, be the primary issue.

Assuming the new method didn't impose a noticeable speed or memory constraint, of course.

I don't see how this is possible. If you offer the full history of all timezones available for all historic time that would be a dramatic expansion of the size of the internal database. At least this would be true without some significant redesign of the time zone class so that each instance of a particular region might share the tz rules with other instances -- currently each instance has a copy so adding the historical perspective would add alot of additional information for each region. Jeff