[tz] [PATCH] Updates for Chile 2013

Juan Correa pottersys at gmail.com
Thu Feb 21 20:50:13 UTC 2013


On Thu, Feb 21, 2013 at 4:54 AM, <tz-request at iana.org> wrote:

> Message: 5
> Date: Thu, 21 Feb 2013 07:42:40 +0700
> From: Robert Elz <kre at munnari.OZ.AU>
> Subject: Re: [tz] [PATCH] Updates for Chile 2013
> To: Petr Machata <pmachata at redhat.com>
> Cc: tz at iana.org
> Message-ID: <16688.1361407360 at eos.noi.kre.to>
> Content-Type: text/plain; charset=iso-8859-1
>
>     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.
>
> kre
>

I'm concerned about extending the new rules from 2013 to the future, as the
decree that changes the DST this year explicitly says these changes will be
valid only on this year; and doesn't void the rules set in 1970 (DST from
September to March).

I think it would be better to stick with a "conservative" approach, as
legally on 2014 DST will end on March until further notice.

-- 
Juan Correa Poblete
PS Labs (http://www.pslabs.cl)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mm.icann.org/pipermail/tz/attachments/20130221/d60cb796/attachment.htm>


More information about the tz mailing list