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 thr
On Fri, 14 Nov 2003, Jonathan Swartz wrote:
> 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 f
On Fri, 14 Nov 2003, Dave Rolsky wrote:
> 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.
I proposed something just short of this *months* ago and nobody even responded to my
RFC.
DT::Q could be either used b
Here's a football to kick around over the weekend:
http://www.mojotoad.com/sisk/dt/
Regarding the sharing of DT::TZ data across the timezone singletons,
I've got an example implementation that demonstrates the principle.
At the above URL you will find some modified versions of TimeZone.pm and
