I work at the Santa Cruz Operation, a company that makes UNIX. I am designing and implementing the part of our installation that sets time zones. A search for complete, thorough timezone information led me to your anonymous ftp site, and I would like to use the information that you make available, if possible.
The best way to do that would simply be to pick up Arthur's *code*, as well, and put it into SCO UNIX (SunOS 4.x, System V Release 4, and many other versions of UNIX have already done so); modulo bugs, it *fully* supports the POSIX standard for the TZ environment variable, as well as supporting the nicer "Olson" scheme (e.g., to get US Pacific time, set "TZ" to ":US/Pacific", rather than to whatever convoluted string is required for the POSIX scheme).
However I am having some trouble reconciling the Rule format with the format we use, which is also the POSIX standard for timezone strings (as far as I can tell, looking at my POSIX doc). The problem is in the area of shifting to and from Daylight Savings Time. Our format is to use a Julian day, a month/week/day, or a week/day format. It's different enough from your Rule format that timezones defined in your format (such as Sun >= 11) do not work in our format for more than a few years at best (is that the 2nd week of the month? The 3rd week? It shifts.)
Unfortunately, as you note, the "Mm.n.d" scheme specified in POSIX does not appear to allow rules of the form "Sun>=11" to be expressed (sometimes it's the Sunday of the 3rd of the weeks in the month that have a Sunday, which would be "Mm.3.0", and sometimes it's the Sunday of the 2nd of the weeks in the month that have a Sunday, which would be "Mm.2.0" - the "n" im "Mm.n.d" doesn't mean "the nth week of the month", it means "the nth of the weeks in the month that actually have a day d", e.g. if d is 0, it's "the nth of the weeks in the month that have a Sunday"). The "Mm.n.d" scheme can, however, specify things such as "third Sunday in the month", which would be "Mm.3.0"; the Olson scheme can also specify that, as "Sun>=15". I believe the way to map from "Mm.n.d" to an Olson-style scheme is that Mm.n.d meaning "nth d-day of month m", maps to IN ON month_name(m) day_name(d)>=(1 + n*7) where "day_name(d)" is the name of day "d", e.g. "day_name(0)" is "Sun", "day_name(1)" is "Mon", etc.. If "1 + n*7" is greater than the number of days in the month, the "ON" field would be "last{day_name(d)}", e.g. Thus, for example: M1.1.0 maps to IN ON Jan Sun>=1 M1.2.0 maps to IN ON Jan Sun>=8 and so on, up to M1.5.0 which would map to IN ON Jan Sun>=36 except that no month has 36 days, so it'd map to IN ON Jan lastSun However, if the number after the ">=" isn't a multiple of 7 plus 1, I don't think there's a way to map that back into an "Mm.n.d" value. If there are any countries where the rules require an Olson-style specification other than "XXX>=(1 + n*7)", that's a strong argument in favor of just picking up the Olson code and using that (given that, as noted, it supports POSIX-style TZ settings, as well as settings that just cause a compiled file to be read in). If there *aren't* any such countries, the time zone files should be cleaned up.