proposed time zone package changes

[Jonathan Leffler]

On Mon, Jul 13, 2009 at 2:54 AM, Robert Elz <kre at munnari.oz.au> wrote:

>    Date:        Sat, 11 Jul 2009 14:07:35 -0400
>    From:        "Dave Cantor" <Dave at Cantor.mv.com>
>    Message-ID:  <4A58D4E7.20949.B6C0C36 at Dave.Cantor.mv.com>
>
>  | I disagree with this.  When a region does not observe DST at all,
>  | the POSIX string simply indicates its abbreviation and offset,
>  | e.g. UTC0 or EST5.   When a region observes DST all year, it's
>  | the same as observing the standard time of the next time zone
>  | eastward all year.   In my opinion, it should simply be coded
>  | that way.
>
> As I understand it, the issue is to deal with regions with time zone
> specifications that cover things that POSIX strings cannot represent.
>
> That is neither regions that have no summer time, nor regions that
> have "summer time all year" (ie: are not in the time zone that would be
> logically appropriate, I assume).
>
> I'm no expert on POSIX strings, but I think the example that caused
> the problem was a region that switched summer time on, but never
> switched it off again - that is (so we were told, and I am willing to
> accept without evidence to the contrrary) something that POSIX strings
> just do not handle.
>


The database would surely just need to encode things so that at some point
in time after the move to 'permanent summer time', the TZ string would
simply be:

    TZ=XYZ-9

for a suitable code XYZ and timezone offset.  This would apply all year
round in perpetuity.  In the year when the switch occurred, the Olson
database would encode the rules appropriately - it can surely handle a year
where there is just one change to the time zone offset.




>
> Of course, this time, the "never switched it off" is just our way of
> currently encoding "no-one has yet even hinted at the end date, so we
> have no idea what to put", which is why the other half of ado's proposed
> fix was just to stick an arbitrary end date on Dhaka's summer time, so the
> problem case goes away for people who don't have the other fix).
>

This problem faces all the data.  There is no assigned date for when the USA
will next change its rules, but I'm sure it will happen, and probably before
I retire.




>
> After all this, I'm not sure what you're objecting to?  There are two
> relevant (proposed) changes - one to just not include a POSIX string when
> it is impossible to make a valid one (if you object to that, why?  And what
> would your alternative be - including invalid strings isn't useful for
> anyone.)


I'm not convinced there is no valid TZ string...the outline value I showed
would be correct (the same as it is for UTC0).  The fact that the time zone
offset that is used indefinitely used to correspond to a daylight saving
time zone offset for the same region is neither here nor there - for the
indefinite future, the time zone for the country becomes a simple fixed
offset from UTC all year round (something that POSIX TZ strings can manage
trivially).


> The other is the arbitrary end date for summer time for Dhaka
> (Bangladesh) - that one makes me a little queasy, but I'm not sure what
> else to do to handle people who have old implementations of zic, and so
> can't get the benefit of the former fix.  If your objection was to
> picking an arbitrary date, then is it better to leave those people with
> compiled files with invalidly formatted data?   Or, if the objection is
> just to the date picked, suggest a better one - we can probably do
> better than "the end of the year" as a guess, though the closer we come
> to reasonable the more likely it is that someone will believe that our
> arbitrary guess is actually based upon some reliable data.  The one time
> that you can be pretty much sure that no-one, however stupid the
> politicians
> are, is ever going to pick to end summer time is midnight, local time,
> new year's eve (ie: 00:00 Jan 1) - as no-one is going to want to deal
> with what it means (or the cost of fireworks) with having two year
> ends occurring just an hour apart...
>


The arbitrary end date is probably a necessary fiction, like the fiction
that the rules in the USA won't change in the future.

-- 
Jonathan Leffler <jonathan.leffler at gmail.com>  #include <disclaimer.h>
Guardian of DBD::Informix - v2008.0513 - http://dbi.perl.org
"Blessed are we who can laugh at ourselves, for we shall never cease to be
amused."
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mm.icann.org/pipermail/tz/attachments/20090713/ff030232/attachment-0001.html