General developer forum

I think I have a solution for the problem you are describing. For each Zone+DST entry in the table, have the FROM year encoded as timestamp as well. We can generate that timestamp at Olson import stage, as GMT timestamp of (local) 00:00:00 if 1st January of the "FROM" year. ("FROM" is the Olson field of the starting year).

So your first step in your time resolution functions is to say "SELECT id from mdl_timezones_bla WHERE from_timestamp < $timestamp AND name='$zonename' ORDER BY from_timestamp DESC LIMIT 1". That'll narrow down on the right rule in one hit.

The other thing you are talking about is memoizing, and I think it makes sense to add some memoizing abilities to these functions. I haven't seen any interesting memoizing features in PHP... Perl has a beautifullly easy to use Memoize module.

the parser is now feature complete, the entry point is the olson_todst($file) function. The following notes apply:

- it's reporting errors as E_USER_NOTICE because we don't want to stop processing and we also want to be able to run from command line -- at least that's how I've been processing and comparing output between runs of different versions.

- it's starting in 1970, which means we compute the zone+rules current in 1970

- it's providing "from_timestamp" field which has the "from" (aka year) field into a (GMT) timestamp of the (local) start of that year. As I posted earlier in this thread, it's an attempt at  having enough info to select the right rule, but it may be in the wrong place.

- the "AT" field in the rules, which ends up in (de)activate_time will sometimes be negative, due to the conversion of wall or standard time to GMT. We need to be able to find a way to deal with it as it is, because we can't really fudge the other activate_* and deactivate_* fields.

- the *_index *_day fields still haven't been updated to the new scheme -- (Jon if you want to hack the parse_on function go for it!)

- the fields in the final nested array may still need changing to match the new table structure -- (Jon you are designing the new table, have you got the colnames you want?)

Here's a sample zone+rules entry:
[rule] => AQ
[gmtoff] => 600
[name] => Australia/Brisbane
[from] => 1971
[apply_offset] => 60
[activate_month] => 10
[activate_time] => 12:00
[activate_index] => -1
[activate_day] => 0
[deactivate_month] => 1
[deactivate_time] => 21:00
[deactivate_index] => 1
[deactivate_day] => -1
[from_timestamp] => 31572000

Bear in mind that if there aren't any DST rules, then things look like:

[rule] =>
[gmtoff] => 480
[name] => Australia/Perth
[from] => 1974
[from_timestamp] => 126259200