Hello, I have been doing extensive work with the tz database, and while the data is quite useful, it is not in the most accessible format. I have had little success using the zic compiler or any of the source code, and have been forced to do my own parsing and analysis of the data. One aspect of the representation of rules I find awkward is the notation for the day on which a rule takes effect. There are rules such as "lastSun" or "Sun>=8", etc. While descriptive, they are are hard to process. I would like to suggest a better approach. It takes the form "d op nn", where 'd' is the day-of-week, 0=Sun to 6=Sat 'op' is a comparison code of '<', '=' or '>', and 'nn' is a 2-digit day number (may be 00 or 32) The comparision code works as follows: '=' nn is an exact value '<' rule describes the last day less than nn '>' rule describes the first day greater than nn Examples: 0>07 first Sun > 7 (same as first Sun >= 8) 0<32 last Sun < 32 (same as "lastSun") 0=27 Sun the 27th of the month When a range of years are involved in a rule, there is no exact day-of-week, and in such cases, '9' may be used as a place-holder: 9=01 the first day of the month, regardless of what day-of-week it is There is little need to use a day-of-week with >, since the value would always be the same. Example: 9>07 means: first day of the month (regardless of day of week) that is > 7 is always 8. It is conceivable that 9<nn could be used, but the only case where it would have any merit is in February: 9<32 last day of the month For months other than Feb, the value is a constant for a given month, and for Feb it depends on the leap-year status. Since no one (that I know of) does anthing about DST in Feb, we can safely eliminate the 9<nn form as well as the 9>nn form. The conversion from existing rules to this format is pretty straightforward: lastSun 0<32 '32' is constant for 'last' Sun>=8 0>07 subtract 1 from the tz rule value Sun<=21 0<22 add 1 to the tz rule value May 1 9=01 for May 1 of any year May 1 1980 4=01 May 1 1980 is a Thursday Hope you find this interesting. Regards, Robert Hodge