4 Commits

Author SHA1 Message Date
aj
216a8d9ff8 brainstorming the flattening algorithm, slight API change 2010-11-09 23:32:25 -08:00
aj
d00937c3e9 lots of gutting. purposes, input, and output were unclear in many places. still broken. 2010-11-08 01:29:15 -08:00
aj
9ad8f3c826 lots of work towards flattening the records. stalled at ezic_rule:next_event/4 2010-11-07 18:32:37 -08:00
aj
329f699e51 alerted to buginess in README. added notes & zic reference. removed local_to_utc conversion for now.
Time comparisons are patently wrong. They do not consider s/w/u/g/z time modifiers, so the comparisons can be off by hours. At least 24 hours within any time or zone change, ezic will give unreliable results.
I think a solution can involve "flattening" the data, starting from the earliest time possible for each zone/rule, going forward.
There exist ambiguous local times for zones and rules. For example, on Nov 7th, in Los Angeles, the times from 1:00:00am to 1:59:59am were repeated, once for PDT and once for PST. Given a local time in that zone between those times, we cannot determine what UTC time is unambiguously. Similar for Zone transitions where fall-back occurs.
2010-11-07 12:52:51 -08:00