Re: [Fwd: DateTime::Duration comparisions]
Doug Treder wrote:
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.
I really, really, really don't like this. If I get two durations I want
to be able to compare them or not compare them. I don't want to have to
handle the 'fuzzy' bits. Here's how you'd have to handle 'might
compare':
my $cmp = eval{ ($dtdurr1 $dtdurr2) };
if ($@) {
$cmp = DateTime-now()-add_durration( $dt_durr1 )
DateTime-now()-add_durration( $dt_durr2 );
$cmp_from_now++;
}
if ($cmp) {
print dtdurr2 is the larger;
print ($cmp_from_now)
? using now() as a base
: for any base;
}
__END__
However, to compare with compare() is much easier:
if ($dtdurr1-compare($dtdurr2) == -1) {
print dtdurr2 is the larger using now() as a base
}
And, to make comparing easier, we could add is_less_than and
is_greater_than and is_equal_to:
sub is_greater_than { (return shift-compare( @_ ) == 1) }
sub is_less_than{ (return shift-compare( @_ ) == -1) }
sub is_equal_to { (return shift-compare( @_ ) == 0) }
Of course, you could always write DateTime::Utils::DurationFuzzyCompare
which could either take a Duration for its new() parameter, or could be
Class::ClassDecorator on top of DateTime::Duration.
Cheers!
Rick
DateTime::TimeZone::Lite and DateTime::TimeZone::Olson::XS
Two thoughts on the TimeZone issue: 1. Create DateTime::TimeZone::Lite. - This would return a subset of the Olson data that assumed the current rules extend infinitely in both directions. - This would not be a prereq, or be installed by DateTime itself. - I suggest we might make this assumption on the grounds that we already make a similar assumption with DateTime: The Gregorian Calendar wasn't used back at the year 0, but DateTime assumes it does. 2. Create DateTime::TimeZone::Olson::XS - The Olson Database is already an open-source, free distributable C library, would we not save considerable space/memory by creating an XS interface to the library? - The DateTime::TimeZone::Olson::XS module would be a part of the DateTime::TimeZone distro, and would be the default, if it can find the Olson database. Otherwise TimeZone falls back on the perlified version. Unfortunately I'm not a C programmer and, although I just read right through perlxs and perlxstut I'm still none-the-wiser ;) Cheers! Rick
Re: [Fwd: DateTime::Duration comparisions]
Dave Rolsky 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 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 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 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). 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. 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?) -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 ...
Re: [Fwd: DateTime::Duration comparisions]
On Sat, 15 Nov 2003, Max Maischein wrote: 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 ... Almost every facet of DateTime stuff is a hornet's nest. It seems simple at first, but the deeper you get into it, the weirder it becomes. -dave /*=== House Absolute Consulting www.houseabsolute.com ===*/
Re: DateTime::TimeZone::Lite and DateTime::TimeZone::Olson::XS
On Sat, 15 Nov 2003, Rick Measham wrote: 1. Create DateTime::TimeZone::Lite. - This would return a subset of the Olson data that assumed the current rules extend infinitely in both directions. - This would not be a prereq, or be installed by DateTime itself. - I suggest we might make this assumption on the grounds that we already make a similar assumption with DateTime: The Gregorian Calendar wasn't used back at the year 0, but DateTime assumes it does. I'm really not sure how useful this is. Imagine you start using this now, then next year some time zone changes it's rules, so you install the latest version. Now all the year-old data is using the new rules, meaning that you end up with bogus conversions. If this were a calendaring app, that'd mean that old entries might suddenly become an hour off for nor apparent reason. 2. Create DateTime::TimeZone::Olson::XS - The Olson Database is already an open-source, free distributable C library, would we not save considerable space/memory by creating an XS interface to the library? No it's not, actually. It's an open-source freely distributable set of a data and a few C programs. The interpretation is up to each system's core library. On Unix boxes, that means libc. Also, this would be limited to using epoch values, which means 32 bit ints. Avoiding this has always ben one of the main goals of the DateTime project! I think an XS implementation of the current API/code would be a much more useful thing. As I said, I'd like to implement it but I'm a bit short on tuits. -dave /*=== House Absolute Consulting www.houseabsolute.com ===*/
[announce] DateTime::Format::ISO8601 0.04
Released to CPAN. Available immediately from: http://kolea.ifa.hawaii.edu/~jhoblitt/pm/DateTime-Format-ISO8601-0.04.tar.gz Changes since 0.03 - require DT 0.18 and DT::F::B 0.77 - recommend Test::Pod 0.95 and File::Find::Rule 0.24 - doc update - test update - fix bug in -YY spec - default handling of 2-digit years is now 0-49 as 20xx and 50-99 as 19xx - add DefaultCutOffYear() - add DefaultLegacyYear() - add base_datetime() - add clone() - add cut_off_year() - add legacy_year() - add new() - add set_base_datetime() - add set_cut_off_year() - add set_legacy_year() Cheers, -J --
DateTime::Format::DateManip test failures
I've been seeing this build error for a couple of months now on at least half a dozen different systems. -J -- /usr/bin/perl Build test t/00load...ok t/01conversionsNOK 3# Failed test (t/01conversions.t at line 69) # got: '2003032300:00:00' # expected: '2003032303:00:00' t/01conversionsNOK 4# Failed test (t/01conversions.t at line 69) # got: '2003032312:00:00' # expected: '2003032315:00:00' t/01conversionsok 6/6# Looks like you failed 2 tests of 6. t/01conversionsdubious Test returned status 2 (wstat 512, 0x200) DIED. FAILED tests 3-4 Failed 2/6 tests, 66.67% okay Failed Test Stat Wstat Total Fail Failed List of Failed --- t/01conversions.t2 512 62 33.33% 3-4 Failed 1/2 test scripts, 50.00% okay. 2/7 subtests failed, 71.43% okay.
