2008/11/24 Olson, Arthur David (NIH/NCI) [E] <olsona@dc37a.nci.nih.gov>:
The differing years on the "max" lines are correct--or, in any event, as correct as can be for now. Since there are two transitions a year--one to DST and one from DST--we do expect two "max" lines. Starting in 2008, Brazil always goes in to DST on the third Sunday of October; thus the "Oct Sun>=15" line. Improvidently, the end of DST is legislated to avoid coinciding with Carnaval; the end of DST is deferred a week if it would fall during Carnaval. So the ending ("Feb") rules need to be done on a year-by-year basis (or at least a year-range by year-range basis), accounting for the plethora of "Feb" rules. The cases are specified through 2038 (the maximum year associated with a signed, 32-bit time_t value). After that (through year "max") the rules say that DST ends the third Sunday of February every year; this is wrong by a week in some cases but is better than nothing.
Just a note.. personally I don't think a knowingly wrong rule is "better than nothing", it forces the sysadmin to fix the clock 2 times. I think when there's no good rule "forever", make it apply only for the known cases and leave it alone so the admin can easily handle it on his own if needed. Not gonna happen anytime soon in this case, but happened almost every year in Brazil before this new rule.
We could get things right using the "yearistype" mechanism; there has already been some grumbling about the advisability of doing so.
-- (nil)