Thanks for the responses!

With fifteen or so developers with all different levels of Perl skills not
all are going to understand or know the specifics of when duration math
might fail.   And the hard part is it might not fail for months or years
after the code is written.

Obviously, they should understand that adding a duration of, say, days may
not mean exactly multiples 24 hours, and it could fail.  But,  I'm
wondering if there's an idiom or rule I could provide them so that the math
will at least not fail.

Like, "always defined durations in terms of hours" (or seconds?) or "always
convert to UTC before adding a duration".

True, there's no easy solution.


>
> >What would happen if duration calculations were always done in UTC?
>
> That would avoid DST-based failures.  It does so by applying a different
> meaning of "day" from that which you're currently using.
>


Again, developers of varying skills come and go and work on existing code.
 So, they may not have any idea that "$start_time" has a timezone or think
about DST issues.  Or that a day isn't always 24 hours.

$access->disable if $start_time->add( days => $day_limit ) < $now;

That might be important contractually that it happens at some point instead
of never.

What if DatTime Duration objects had a flag to say do the math in UTC?
 Would that avoid the problem if it possibly failing?

$access->disable if $start_time->add( days => $day_limit, in_utc => 1 ) <
$now;



> Maybe you actually want a definite UT time for the end of the period.
> If that's the case, you probably want to interpret the duration in UT.
> Or maybe you need the end of the period to be defined in local time.
> In that case you'd be better just storing a notional local time without
> regard to current projection of whether DST will skip it.  (You do that
> with DateTime by using the "floating" pseudo-timezone.)
>

In my experience the floating times open up other headaches.   We store all
times with a timezone -- we would rarely have something like "9am your
time" because of the ambiguity.


Thanks very much for the comments.


-- 
Bill Moseley
mose...@hank.org

Reply via email to