On Mon, Jul 13, 2009 at 2:54 AM, Robert Elz <kre@munnari.oz.au> wrote:
Date: Sat, 11 Jul 2009 14:07:35 -0400 From: "Dave Cantor" <Dave@Cantor.mv.com> Message-ID: <4A58D4E7.20949.B6C0C36@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@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."