<br><br><div class="gmail_quote">On Mon, Jul 13, 2009 at 2:54 AM, Robert Elz <span dir="ltr"><<a href="mailto:kre@munnari.oz.au">kre@munnari.oz.au</a>></span> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Date: Sat, 11 Jul 2009 14:07:35 -0400<br>
From: "Dave Cantor" <<a href="mailto:Dave@Cantor.mv.com">Dave@Cantor.mv.com</a>><br>
Message-ID: <<a href="mailto:4A58D4E7.20949.B6C0C36@Dave.Cantor.mv.com">4A58D4E7.20949.B6C0C36@Dave.Cantor.mv.com</a>><br>
<div class="im"><br>
| I disagree with this. When a region does not observe DST at all,<br>
| the POSIX string simply indicates its abbreviation and offset,<br>
| e.g. UTC0 or EST5. When a region observes DST all year, it's<br>
| the same as observing the standard time of the next time zone<br>
| eastward all year. In my opinion, it should simply be coded<br>
| that way.<br>
<br>
</div>As I understand it, the issue is to deal with regions with time zone<br>
specifications that cover things that POSIX strings cannot represent.<br>
<br>
That is neither regions that have no summer time, nor regions that<br>
have "summer time all year" (ie: are not in the time zone that would be<br>
logically appropriate, I assume).<br>
<br>
I'm no expert on POSIX strings, but I think the example that caused<br>
the problem was a region that switched summer time on, but never<br>
switched it off again - that is (so we were told, and I am willing to<br>
accept without evidence to the contrrary) something that POSIX strings<br>
just do not handle.<br>
</blockquote><div><br><br>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:<br><br> TZ=XYZ-9<br><br>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.<br>
<br><br> </div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><br>
Of course, this time, the "never switched it off" is just our way of<br>
currently encoding "no-one has yet even hinted at the end date, so we<br>
have no idea what to put", which is why the other half of ado's proposed<br>
fix was just to stick an arbitrary end date on Dhaka's summer time, so the<br>
problem case goes away for people who don't have the other fix).<br>
</blockquote><div><br>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.<br><br><br> </div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<br>
After all this, I'm not sure what you're objecting to? There are two<br>
relevant (proposed) changes - one to just not include a POSIX string when<br>
it is impossible to make a valid one (if you object to that, why? And what<br>
would your alternative be - including invalid strings isn't useful for<br>
anyone.) </blockquote><div><br>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).<br>
</div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">The other is the arbitrary end date for summer time for Dhaka<br>
(Bangladesh) - that one makes me a little queasy, but I'm not sure what<br>
else to do to handle people who have old implementations of zic, and so<br>
can't get the benefit of the former fix. If your objection was to<br>
picking an arbitrary date, then is it better to leave those people with<br>
compiled files with invalidly formatted data? Or, if the objection is<br>
just to the date picked, suggest a better one - we can probably do<br>
better than "the end of the year" as a guess, though the closer we come<br>
to reasonable the more likely it is that someone will believe that our<br>
arbitrary guess is actually based upon some reliable data. The one time<br>
that you can be pretty much sure that no-one, however stupid the politicians<br>
are, is ever going to pick to end summer time is midnight, local time,<br>
new year's eve (ie: 00:00 Jan 1) - as no-one is going to want to deal<br>
with what it means (or the cost of fireworks) with having two year<br>
ends occurring just an hour apart...<br></blockquote></div><br><br>The arbitrary end date is probably a necessary fiction, like the fiction that the rules in the USA won't change in the future.<br clear="all"><br>-- <br>
Jonathan Leffler <<a href="mailto:jonathan.leffler@gmail.com">jonathan.leffler@gmail.com</a>> #include <disclaimer.h><br>Guardian of DBD::Informix - v2008.0513 - <a href="http://dbi.perl.org">http://dbi.perl.org</a><br>
"Blessed are we who can laugh at ourselves, for we shall never cease to be amused."<br>