Eric Brine wrote: >I can't figure out how to search only down to the minute without causing it >to find the wrong answer on days with two midnights.
In those fairly common cases, where DST ending causes time to jump back from 01:00 to 00:00, you want to consistently get the earlier midnight. This doesn't pose any real difficulty. Finding a UT time that corresponds to local time 00:00 doesn't tell you that you've found the real boundary: it only tells you that the real boundary is no later than this time. You continue the binary search. The criterion you use, to decide which range endpoint to replace with the bisected timestamp, is whether the local time to which it corresponds is greater than or equal to 00:00 on the target day. You should end up with two consecutive UT minutes, the earlier of which precedes the target day in zone time, and the later of which falls on or follows the target day in zone time. The only situation that would really screw up this search is if time jumped back from, say, 00:30 to 23:30, making the span of a calendar date discontinuous in zone time. (Is this what you meant by "two midnights"?) No zone actually does this. While changing the effective length of a local day is quite palatable, making a day discontinuous is too big an inconvenience. Note that this is inconvenient *for people in the zone*, unlike things like there being no local 12:00, which is inconvenient *for programmers* and happens all the time. -zefram
