[tz] [PATCH] Updates for Chile 2013
Petr Machata
pmachata at redhat.com
Thu Feb 21 12:12:33 UTC 2013
Robert Elz <kre at munnari.OZ.AU> writes:
> Date: Wed, 20 Feb 2013 22:55:04 +0100
> From: Petr Machata <pmachata at redhat.com>
> Message-ID: <m2ehgaljwl.fsf at 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.
This makes sense, I didn't notice that the 2012 rule actually applies.
Thanks,
PM
More information about the tz
mailing list