proposed time zone package changes

[Dave Cantor]

On 13-Jul-2009, Robert Elz wrote:

From:	Robert Elz <kre at munnari.OZ.AU>
Date sent:	Mon, 13 Jul 2009 16:54:56 +0700

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

What I'm objecting to is not generating a POSIX-style TZ string 
when it is possible to do so.   It seems to me that the string 
"XDT-2" would be a workable TZ string for an exemplary fictitious 
location Fictitious/Xyzzy located 1 hour east of UTC, but using a 
time 2 hours east of UTC all year.

Maybe I'm missing some key point (other than that POSIX TZ 
strings are insufficient for expressing all the rules that 
political entities actually enact).

Dave C.