Bill Moseley wrote: >The code Eric pointed me to sets the hour to 12 on a floating $dt and then >sets the timezone. Sounds like there's cases where that could still fail.
Right, that's broken. That's not the algorithm I was proposing. You should search among *UT* times, and the only kind of conversion you need is to represent a given UT time in zone terms, which doesn't run into this problem. There is no need to specify a local time and convert it to UT or otherwise process it. Your initial search range is centred around the UT start of the specified day, with a radius around that centre point of 1440 minutes or so. >This is for a form where a user can enter a start and end date (not a time) >and expect to see all events during those days. i.e. From 2016-04-01 to >2016-04-30. To handle the inclusive upper day boundary, increment the supplied date (calendar arithmetic only, ignore zone behaviour) to get an exclusive upper day boundary. Find the beginning of that day in zone time to get an exclusive upper UT time boundary. >The form's defaults are suppose to be the dates for the *current* start and >end of the month *in the user's time zone*. For this part, you just take the current UT time and represent it in zone terms. That tells you what month to default to. -zefram
