[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