Date: Wed, 20 Feb 2013 22:55:04 +0100 From: Petr Machata <pmachata@redhat.com> Message-ID: <m2ehgaljwl.fsf@redhat.com> | I decided to apply the transition dates to single years only--the DST | policy is reevaluated every year anyway. I think that's a mistake - you're guaranteeing that the data is going to be wrong, rather than simply making it likely. I'd suggest that the data be changed as ... --- southamerica.was 2012-07-25 21:13:46.000000000 +0700 +++ southamerica 2013-02-21 07:37:16.000000000 +0700 @@ -1277,10 +1277,8 @@ Rule Chile 2010 only - Apr Sun>=1 3:00u 0 - Rule Chile 2011 only - May Sun>=2 3:00u 0 - Rule Chile 2011 only - Aug Sun>=16 4:00u 1:00 S -Rule Chile 2012 only - Apr Sun>=23 3:00u 0 - -Rule Chile 2012 only - Sep Sun>=2 4:00u 1:00 S -Rule Chile 2013 max - Mar Sun>=9 3:00u 0 - -Rule Chile 2013 max - Oct Sun>=9 4:00u 1:00 S +Rule Chile 2012 max - Apr Sun>=23 3:00u 0 - +Rule Chile 2012 max - Sep Sun>=2 4:00u 1:00 S # IATA SSIM anomalies: (1992-02) says 1992-03-14; # (1996-09) says 1998-03-08. Ignore these. # Zone NAME GMTOFF RULES FORMAT [UNTIL] That is, it turns out that the rules we inserted for 2012 apply for 2013 as well (except we were conservative last year, and assumed the change then was just a one year thing, and put the older dates back for 2013). So, the patch above just assumes that the 2012/2013 strategy will continue forwards, which it might ... it is also possible that it won't, and we will need to change it again next year (or even again later this year) but some kind of reasonable guess is better than simply assuming that summer time is going to start next September, and then never end. kre