On Sat, Apr 23, 2016 at 10:14 AM, Zefram <zef...@fysh.org> wrote: > Bill Moseley wrote: > > hour => 12, # Assume this exists > > This does not always exist. Africa/Khartoum on 2000-01-15, for example. > In fact, thanks to cases such as Pacific/Apia on 2011-12-30, not only is > there no hour that exists on every day in every zone, there are actually > some zone days for which no hour exists. >
$ perl -le 'use DateTime; my $dt = DateTime->new( year => 2000, month => 1, day => 15, hour => 12 )->set_time_zone( "Africa/Khartoum")' Invalid local time for date in time zone: Africa/Khartoum Fun. 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. If I cannot assume hour 12 exists (or assume anything) how can I find my starting valid $dt in the target time zone to look back for the starting time? > > >And for the end time of the month (to the second): > > Rather than subtract a second and use a <= comparison, it's cleaner to > use the start time of the next month and a < comparison. > Yes, that makes sense. 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. 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*. I then need to convert those into a timestamp (including offset) that the database can compare against. The database's session is not in the target timezone so I cannot simply compare the date part. > > >I was thinking of an implementation that assumed DST change happened at an > >hour boundary and simply try incrementing hours until no more exceptions. > > That's a bad assumption. You can assume *minute* boundaries, but > not hours. > > -zefram > Thanks! -- Bill Moseley mose...@hank.org
