5

I am trying to install the perl module Date::Calc version 6. It is part of gnuCalc and failed when installed with it. I chose to manually download Date::Calc and install it but it gave exactly the same errors which are shown below. Since Date::Calc is not limited to gnuCalc, I was hoping someone could point me in a direction to solve this.

I am on Windows 7 64bit. Perl is strawberry Perl ver 5.18.2002

Thanks in advance.

E:\Downloads\Date-Calc-6.3>perl Makefile.PL

*************************************************************
****** BEWARE: Use "make install UNINST=1" to install! ******
*************************************************************

Checking if your kit is complete...
Looks good
Generating a dmake-style Makefile
Writing Makefile for Date::Calc
Writing MYMETA.yml and MYMETA.json

E:\Downloads\Date-Calc-6.3>C:\strawberry\c\bin\dmake.exe
cp lib/Date/Calc/Object.pod blib\lib\Date\Calc\Object.pod
cp lib/Date/Calc.pm blib\lib\Date\Calc.pm
cp lib/Date/Calendar/Profiles.pod blib\lib\Date\Calendar\Profiles.pod
cp lib/Date/Calendar.pm blib\lib\Date\Calendar.pm
cp lib/Date/Calendar.pod blib\lib\Date\Calendar.pod
cp lib/Date/Calc/Object.pm blib\lib\Date\Calc\Object.pm
cp lib/Date/Calc/PP.pm blib\lib\Date\Calc\PP.pm
cp lib/Date/Calendar/Profiles.pm blib\lib\Date\Calendar\Profiles.pm
cp lib/Date/Calc/PP.pod blib\lib\Date\Calc\PP.pod
cp lib/Date/Calendar/Year.pod blib\lib\Date\Calendar\Year.pod
cp lib/Date/Calendar/Year.pm blib\lib\Date\Calendar\Year.pm
cp lib/Date/Calc.pod blib\lib\Date\Calc.pod

E:\Downloads\Date-Calc-6.3>C:\strawberry\c\bin\dmake.exe test
C:\strawberry\perl\bin\perl.exe "-MExtUtils::Command::MM" "-MTest::Harness" "-e"
 "undef *Test::Harness::Switches; test_harness(0, 'blib\lib', 'blib\arch')" t/*.
t
t/f000.t .. ok
t/f001.t .. ok
t/f002.t .. ok
t/f003.t .. ok
t/f004.t .. ok
t/f005.t .. ok
t/f006.t .. ok
t/f007.t .. ok
t/f008.t .. ok
t/f009.t .. ok
t/f010.t .. ok
t/f011.t .. ok
t/f012.t .. ok
t/f013.t .. ok
t/f014.t .. ok
t/f015.t .. ok
t/f016.t .. Failed 16/25 subtests
t/f017.t .. ok
t/f018.t .. ok
t/f019.t .. ok
t/f020.t .. ok
t/f021.t .. ok
t/f022.t .. ok
t/f023.t .. ok
t/f024.t .. ok
t/f025.t .. ok
t/f026.t .. ok
t/f027.t .. Failed 22/46 subtests
t/f028.t .. Failed 22/46 subtests
t/f029.t .. ok
t/f030.t .. ok
t/f031.t .. ok
t/f032.t .. ok
t/f033.t .. ok
t/f034.t .. ok
t/f035.t .. ok
t/f036.t .. ok
t/f037.t .. ok
t/m001.t .. ok
t/m002.t .. ok
t/m003.t .. ok
t/m004.t .. ok
t/m005.t .. ok
t/m006.t .. ok
t/m007.t .. ok
t/m008.t .. ok
t/m009.t .. ok
t/m010.t .. ok
t/m011.t .. ok
t/m012.t .. ok
t/m013.t .. ok

Test Summary Report
-------------------
t/f016.t (Wstat: 0 Tests: 25 Failed: 16)
  Failed tests:  1-4, 6-7, 9-12, 15-17, 21-23
t/f027.t (Wstat: 0 Tests: 46 Failed: 22)
  Failed tests:  7-15, 22, 24-27, 30-35, 44-45
t/f028.t (Wstat: 0 Tests: 46 Failed: 22)
  Failed tests:  7-15, 22, 24-27, 30, 32, 34-37, 44-45
Files=51, Tests=3381,  3 wallclock secs ( 0.20 usr +  0.01 sys =  0.22 CPU)
Result: FAIL
Failed 3/51 test programs. 60/3381 subtests failed.
dmake.exe:  Error code 255, while making 'test_dynamic'
mseifert
  • 5,390
  • 9
  • 38
  • 100
  • 1
    It looks like there is a problem with Date::Calc right now: Failed 3/51 test programs. 60/3381 subtests failed. Makefile:890: recipe for target 'test_dynamic' failed make: *** [test_dynamic] Error 255 – senorsmile Jan 11 '15 at 06:06
  • 2
    It also looks like there are open bugs: https://rt.cpan.org/Public/Dist/Display.html?Name=Date-Calc – senorsmile Jan 11 '15 at 06:07
  • 1
    If you don't specifically need Date::Calc, I would recommend [DateTime](https://metacpan.org/pod/DateTime) instead. It has better functionality, interface and is far better maintained. – Schwern Jan 11 '15 at 20:28
  • @Schwern - Thanks, Date::Calc is a dependency for Finance::Quote in gnuCash and is used for online price retrieval (stock quotes). Thanks also for pointing out the patch at the end of the bug reports. – mseifert Jan 11 '15 at 22:06

2 Answers2

6

Do not replace bad tests with good ones.

The purpose of these tests is to test. If there's a problem, you need to know about it, and not sweep it under the rug. Resolve the issue one way or another. Is there a problem with something on your system, or is this a problem with the test itself. If this is a problem with the test, does it still affect you? If this is a system problem, is this something you might run into? For example, let's say there's a test that checks for connectivity between your system and a Windows system. If you don't connect to Windows systems, maybe that particular test doesn't apply to you.

If you have a test failure, go to the MetaCPAN webpage for that module, and check the left hand side for issues to see if someone else is getting the same errors. (Bug #101232 for Date-Calc: Test suite started to fail since 2015-01-01 - Happy New Year!).

There's also a QA testers CPAN webpage, but it's down right now. The QA testers webpage will show you the various Perl versions, module versions, platforms, and show you which tests are failing on particular platforms on which versions. You might need to install an alternative version of the module.

Only once you've determined that the failed test doesn't necessarily apply to you, do a force install:

cpan> force install Date::Calc

This will run through the entire install, except that it will skip all testing. (Or maybe it still tests, but doesn't fail if a test fails.). The module will still fail on compiler errors, or if something can't get written to your system. It merely ignores tests.

This should be the last desperate attempt to get something installed. You've should have already resolved that the failed tests are bugs or not meaningful for you. Or, someone is standing beside you with a gun to your head saying, "Install that module, or I'll pull the trigger!".

Or, you can decide to heck with it, and simply use another module -- especially a module that's already included in the standard Perl distribution like Time::Piece. If this is a new Perl program, you might as well use Time::Piece since it's the official time calculation module for Perl.

Okay, it's hard to say whether something is official or not, but Time::Piece is included in all Perl installations since 5.10, and Date::Calc, although more popular, isn't. However, now that Time::Piece now part of the official install, it's more likely to be included on a system where you're running your Perl program. It also means that more people are testing it, and that more users are using it, and that bugs discovered are more likely to be fixed.

If this is a new Perl program you're writing, consider using Time::Piece instead of Date::Calc.

David W.
  • 105,218
  • 39
  • 216
  • 337
  • 2
    At the end of that bug report there is a patch to fix the failing tests. https://rt.cpan.org/Public/Bug/Display.html?id=101232#txn-1450438 – Schwern Jan 11 '15 at 20:26
  • 1
    Great answer. I solved it differently, but you method is preferable. In my case, Date::Calc was a dependency for Finance::Quote, so I couldn't use another module (to my knowledge). I was able to verify the bug reports were the source of the failing tests and weren't likely to be an issue for me. It was my wife with the gun to my head after too many hours of trying to get it installed... – mseifert Jan 11 '15 at 22:02
  • 1
    Interestingly enough the mentioned patch only patches the 3 test files. Doesn't change the code at all. – mseifert Jan 11 '15 at 22:40
  • 1
    @mseifert Yes, it was a bug in the test code. An assumption about the current date which is no longer true. – Schwern Jan 12 '15 at 02:02
  • Fun, fun, fun! The _error_ is actually in the GNU C _time_ functions. The assumption of the GNU time functions is that if the two digit years are assumed to be within a fifty year time period of the current year. In 2014, `01/15/64` was assumed to be Jan, 15, 1964 since 1964 is fifty years ago. However, in 2015, the new assumption is that `01/15/64` is actually 2064 since 1964 is more than fifty years ago. In POSIX, the cutoff is ***always*** 1969. – David W. Jan 12 '15 at 14:45
  • I'm not fond of the patch. The tests found an edge condition which should actually be tested. Two digit years more than 50 years ago are interpreted in the future. Two digits years less than 50 years ago are interpreted in the past. The test should also test the OS and make sure the OS agrees with this division. I haven't tested, but I believe on Macs, the division will always be 1969. – David W. Jan 12 '15 at 15:02
  • @DavidW., I've seen a few questions of the format "Module X fails on WIndows, what do I do", and I think this is one of the best answers. Any objections if I write up a community wiki Q/A using this answer as the base? – dsolimano Jun 03 '15 at 19:02
  • Just posted that and linked to here so the internet can give you some internet points - http://stackoverflow.com/questions/30738541/my-perl-module-from-cpan-wont-install-and-has-tests-failing-what-do-i-do. Any improvements you could suggest would be appreciated. – dsolimano Jun 09 '15 at 17:09
0

Date::Calc manual says: If the year is given as one or two digits only (i.e., if the year is less than 100), it is mapped to a "window" of +/- 50 years around the current year, as described by the "Moving_Window()" function (see further below). So i had to say the patch proposed patch is correct, at least for the next 50 years

Angelo Naselli
  • 47
  • 7