Brian S O'Neill wrote:
The current tz parsers seem to go quite fast, so it doesn't seem worth the trouble to optimize the format. Also keep in mind that the O(logN) searches don't need to exist, as hashtables are often used instead to manage symbols. This optimization is used by one and two pass parsers.
Since the full set of tz rules is fairly small, the parser can read all the rules in memory and process them there. The biggest cost is disk I/O for the first pass, and the second pass is just in memory and costs nothing in comparison.
I'm not too sure how zic works, but the tz parser I wrote does everything I described above.
I guess Arthur previously settled it on the grounds of compatibility with user-defined data. :-) Works for me. Thanks, Liviu