Hi Clay,

I thought this bug had been clobbered, too, in March 2009:

http://www.projectpluto.com/update8e.htm#dst_fix

I don't think this is the same bug. That one happened due to
daylight "saving" time starting or ending in a month in which the
first day of that month was a Sunday. 1 November 2011 was a
Tuesday. And _that_ bug is indeed fixed. I assume this is
something completely different.

I'd say the bug is not in the "current" behavior (TOFFSET=0 is
exactly what you ought to have) but in what it was doing before.
The TOFFSET=-1 shouldn't have been necessary.

Have you needed to do similar switching at past DST switchovers?
If so, were they also not on the actual day of the switch? Anybody
else have data to report on this one?

I'm not seeing this particular bit of misbehavior in Guide (though
I've not tried it on Win7 yet.) But I've also resurrected some test
software I wrote when the original bug arose, which exercises various
functions (both Windows API ones and standard C ones). That led me
to find and fix the original bug.

Now, though, I'm seeing some pretty odd behavior in the test
program that I've yet to figure out. Which I'm hoping will lead me
to understand the odd behavior you (and others) are seeing in Guide
itself. Stay tuned...

(You wouldn't think handling time zones would be this tricky,
would you? Well, maybe some weirdnesses such as using different
rules for different parts of the world, which change from year to
year... and there's the lunacy associated with 2:30 AM local time
not occurring at all on one day in spring, and occurring twice on
one day in fall. It does lead to a lot of hair-pulling. I really
thought it was fixed once and for all. Foolish me!)

-- Bill