Bill Moseley wrote: >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?
Depends how broad your "anything" class is for durations. Calendar durations are not arithmetically well behaved, and there are several distinct ways in which calendar datetimes can fail to exist. >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. You need to decide what you actually mean by "day" when describing these expiry periods. You also need to decide whether you actually need a definite DateTime to represent the end of the period. Consider, especially when the period is years long, that DST rules are liable to before the period ends. Currently you're performing the addition in local time and (by virtue of putting the result into a DateTime with specified time zone) converting the result to UT based on the current best guess of what offset the zone will have at that time. 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.) -zefram
