proposed time zone package changes
jonathan.leffler at gmail.com
Mon Jul 13 13:38:02 UTC 2009
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
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
> 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
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
> 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
> 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
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the tz