On 2011-04-21 18:17, Luke Camden wrote:
Hi all,
Apologies for digging up the past, but did this lead to anything? Did time_zone_base prove to be an adequate abstraction in this case?
Best regards, Luke
Hey Luke, unfortunately my work didn't lead to anything yet except for having implemented the ability to read and use the binary format of the timezone database files (both the 32 and 64 bit parts). time_zone_base has a couple of presumptions which prevent a correct implementation of the Olson database: 1) dst_local_start_time / end_time assumes one such event per year (may be less or more in time zone transition years / countries that don't do DST). A correct interface should assume a series of zone transition points (usually two per year for a given area/location). 2) all *zone_name, *zone_abbrev functions should be a function of time, i.e., it needs a ptime parameter. The zone naming may change over time (e.g., if a country changes their time zone). Cheers, Rutger