proposed time zone package changes

[Robert Elz]

    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.

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