Re: [Fwd: DateTime::Duration comparisions]
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. Jon - Original Message - From: Doug Treder [EMAIL PROTECTED] To: [EMAIL PROTECTED] Cc: Jonathan Swartz [EMAIL PROTECTED]; Dave Rolsky [EMAIL PROTECTED]; Max Maischein [EMAIL PROTECTED]; datetime @ perl . org [EMAIL PROTECTED] Sent: Friday, November 14, 2003 4:49 PM Subject: Re: [Fwd: DateTime::Duration comparisions] The fuzzy logic that was being described earlier on the list is more attractive. There are definitely edge cases where two durations cannot be compared and should throw exception. But most of the spectrum is actually comparable, depending on the units being compared: 30 seconds is always less than 31 seconds, 1 day is always less than 1 month. In fact just taking the worst case for every unit still leaves most of the spectrum comparable. You can determine a span of worst fuzziness for each unit (months are fuzzy for at least 3 days, possibly 4) and throw exceptions if the duration comes within that range. -D [EMAIL PROTECTED] wrote: Jonathan Swartz [EMAIL PROTECTED] wrote: Yes, that is technically true. However, it is -so- intuitive and tempting to compare two durations (because other mathemetical operators work, and because you can compare two datetimes), that IMO it would be appropriate to specifically overload those operators to throw an error. Or to have it compare them anchored at the current time. Anything but letting it compare the reference values. I think Jon has a very astute point here. I used to just compare durations without thinking. It was only when I started getting strange errors that I looked through the module and realised there was no comparison overloads. If you look at 'closest' in the old Event::Easter you'll see this. Unfortunately the tests provided returned the right thing when comparing the references. Of course this was just a fluke and only allowed the tests to pass. I would prefer to see these overloads die, preferably painfully, so that people realise they can't overload duration comparissons. However, at the same time, I'd like to implement $dtdur-compare($dtdur2, $basedt) which would return the normal -1, 0 or 1 from $basedt. If $basedt is not set, then DateTime-now is used. This would mean we could die with DateTime::Duration cannot overload comparison operators. For more information see perldoc DateTime::Duration. To compare durations see the compare method in the same document. Cheers! Rick
Re: [Fwd: DateTime::Duration comparisions]
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 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 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 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. -dave /*=== House Absolute Consulting www.houseabsolute.com ===*/
Re: [Fwd: DateTime::Duration comparisions]
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 by this 'compare' class or be extended to include comparison operators. Two DT::Q objects could be compared deterministically. -J -- From [EMAIL PROTECTED] Fri Nov 14 17:40:01 2003 Date: Sun, 17 Aug 2003 16:02:09 -1000 (HST) From: Joshua Hoblitt [EMAIL PROTECTED] To: DateTime [EMAIL PROTECTED] Subject: [RFC] DateTime::Quantitative was Re: Subtraction Broken? I'm not too sure about the name. I wanted to make sure it couldn't be confused with DateTime::Duration and still be meaningful. Is this the best approach? I can't see this type of functionality being cleanly implemented in DT::Duration. -J -- DateTime::Quantitative - returns duration values normalized to a fixed point in time -new( datetime = $dt, duration = $dtd ) Like DT::Duration it would provide: -years; -months; -weeks; -days; -hours; -minutes; -seconds; -nanoseconds; -sign; -is_positive -is_zero -is_negative In addition: -clone -datetime -duration returns the component object If DT::Q is mutable (might not be a good idea) it would also include: -set_datetime( object = $dt ) -set_duration( object = $dtd ) updates the component object No math operators would be overloaded but perhaps stringification would be allowed.
timezone data overlay -- an implementation
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 parse_olson. In order to test you'll have to run parse_olson in your test distro -- something like tools/parse_olson --dir ./olson --version 2003d, presuming you've unpacked the Olson goods in ./olson. I've also included a 'tzt' script that shows some stats of the data sharing in action. What this stuff does is share data references, sometimes arrays, sometimes of certain objects, in all of the spots where they are repeatedly used across the timezone singletons. My solution will probably set of encapsulation klaxons in many of your minds -- but so long as these singletons are relatively static objects this should not be relevant. Some notes: 1) The data refs are handled via a _juxtaposition() class method 2) No preloading of zones or data is necessary. 3) There is a JUXTA_THRESHOLD constant that controls when this sharing behavior is invoked. Currently this is set to 25, so the sharing only starts happening if you're taking more than a walk around the world. Performance should not be impacted otherwise. 4) I'm currently taking the signatures of the data structures using Digest::MD5 and Data::Dumper. This is just the first way that came to mind, there could be better ways. 5) If we want to make dependencies on such modules optional, the sharing behavior can be made to invoke only if the requisite modules are present on the system. 6) Determining the signature of data structures could be made optional if we're willing to store the structures in a data file somewhere that could be queried at need. (not sure if I like that) 7) Coding style was off the cuff. If the behavior is deemed desirable, we can rework it more elegantly. 8) I was working off of the latest CVS versions. I'm unsure if it works with the latest CPAN release. So if you have time and the inclination, feel free to give it a whirl. Cheers, Matt
