> Seems like you could just skip step 3 and call localtime() with fields
> indicating midnight of the specified date. Then use the complete
> localtime result (don't discard any fields) and you should be OK, no?
Pretty sure this won't work, since the complete localtime result will
not be local midnight, which is the expected result. The problem is that
I don't know what the actual time zone (and DST status) is until *after*
converting from UTC to local. And when the input type is "date" I have
no time zone context to use as a hint.
Rotating to UTC noon solves some problems since converting from UTC to
local time will always stay within the same local calendar day. But it
falls down on the DST transition days, as we've noticed.
I started playing with mktime(), which would seem to be the right thing,
but it isn't clear from my docs that this routine will work without the
time zone fields filled in. Well, no matter what the docs say it seems
to interact badly with my code and I get segfaults a few lines farther
along. I'm poking at it to track down the problem.
- Thomas
