I agree, while it would be explainable in hindsight, it's not good to have scripts blow up because they hit boundaries, even if the programmers should rethink his algorithm...I guess this boils down to four choices:
1) give an arbitrary answer 2) give a reasonable answer that may depend on the current time (add both durations to the current time and compare the resulting times) 3) give an answer if it is correct for all times, throw an exception otherwise 4) always throw an exception
The current behavior is (1). I still favor (2), because it never throws an exception. The problem with (3) is that if you write code that compares arbitrary durations, it will work most of the time (e.g. during testing) but will occasionally throw an exception (e.g. once you're in the wild). It also seems more complicated to implement and document, though maybe not by much.
I agree. Working quietly most of the time and occasionally throwing an exception that will be hard to explain ("Duration exceeds fuzzy comparison limits") is not a good behavior.
I wouldn't want to use DateTime->now(), but a global DateTime object that is initialized at script startup - that way you always get consistent comparisions throughout the run of the script (much like -M).I don't mind the idea of adding a compare() class method that accepts a base datetime and uses DateTime->now, per Rick's suggestion.
Overloading comparision to die might be sensible if it were clear that the situations where comparision is meaningless were happening often, but I'm not convinced - in most cases, there is a sensible way of comparing two DT::Ds even without a reference point in time, and with a reference point in time the dubious situations become even fewer - so I'm in favour of (2), as this solves the problem I am interested in (and what good are durations if you can't look at two and decide which one is longer?)Overloading comparison to explicitly die also seems reasonable. It's annoying the first time it happens, but as I said in my "Industrial Strength Perl" presentation, it's better to die before you've screwed up all your data than afterwards.
-max
PS: I didn't know that this was some hornets nest I stirred up again - it was just a problem I wanted to solve for myself ...
