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. 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). 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.) 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... kre