proposed time zone package changes

[Robert Elz]

    Date:        Mon, 13 Jul 2009 10:30:20 -0400
    From:        "Olson, Arthur David (NIH/NCI) [E]" <olsona at dc37a.nci.nih.gov>
    Message-ID:  <B410D30A78C6404C9DABEA31B54A2813029A0753 at nihcesmlbx10.nih.gov>

  | In a "permanent DST" situation, a POSIX TZ string such as...
  | 	TZ=XDST9
  | ...can get almost everything right, but the tm_isdst indicator in tm
  | structs will end up being set to zero.

That would apply to my suggestion as well - but does it matter?
That is, we're quite prepared to generate what we are almost certain
are incorrect timestamp results, and then we quibble about whether or
not the incorrect answer is "correctly" pretending to be summer time ??

Any real permanent switch (Dhaka's isn't really intended, that seems clear)
would be implemented as a zone change, not permanent summer time anyway
(by everyone, not just us).   That's the way the changes in the US zones
were implemented (the ones that recently jumped from one timezone to
another).  To ease the change for residents, it was explained as "we
just won't set the clocks back when everyone else does" (or so I understand
it) but no-one really considered this to be summer time in perpetuity.

To do better at this for this year though, than what I suggested in the
last message, we could leave Dhaka as a switch to summer time on June 19,
then pick some plausible date (end of October perhaps) for a switch back
to summer time, encode that switch, and then same instant, switch the
time zone one hour ahead.  That way (aside from the tm_isdst value) we
get the same effect as now, without upsetting old zic's, and without
needing a fictional (visible) switch back event included.

kre