Last night abou 2:15am we had some automated tests fail with this error:
Invalid local time for date in time zone: America/Los_Angeles
The problem was that (for some reason) we had a duration object of ( years
=> 7, days => 1 ) which we added to DateTime->now which ended up March 8,
2020 which is a DST change -- and 2:15am does not exist in that time zone
on that date.
If $dt and $duration can be anything, what's the best way to prevent adding
a $duration to a $dt and having it land on a non-existent date?
I realize that durations are a bit ambiguous, but is it reasonable to write
something like
$expires_time = $start_time->clone->add( days => $expire_days ); # or
even ( years => 7, days => 1 ) like above
and not have it throw an exception? I suspect most of us expect (and
hope) that $expires_days in the future will exist. Or should we always
write:
$dt->add( hours => $expires_days * 24 );
What would happen if duration calculations were always done in UTC?
$tz = $dt->time_zone;
$dt->set_time_zone( 'UTC' );
$dt += $duration;
$dt->set_time_zone( $tz );
What advice should I give to our developers about adding durations safely?
It's a common operaton in our apps.
Thanks,
--
Bill Moseley
[email protected]
