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