| Subject: | Fail reports in CPAN Testers |
Full disclosure: I am the co-maintainer of C<DateTime::Event::Easter>.
This RT ticket is a memo to myself for the 1.09 release. This is also
some kind of post-release notes (that is, post 1.08) to CPAN users who
want to know more about this module before installing it.
The short version
The CPAN Testers red reports do not point at a serious bug in
C<DT::E::Easter>, but at a minor bug in the test file F<t/08as_span.t>
(or possibly F<Makefile.PL>). Fixed in the 1.09 release.
The long version
If you have looked at the CPAN Testers results
http://matrix.cpantesters.org/?dist=DateTime-Event-Easter+1.08
you have noticed there are 8 red reports (Fail). They seem to point at
Windows. On the other hand, there are 2 green reports (Pass) for
Windows and 1 Fail report for Linux. So actually, the failure is not
associated with the operating system.
If you read each one of the 8 Fail reports, you notice that the
failure is the same: always in F<t/08as_span.t>, and always associated
with the Julian dates 2019-04-08 and 2019-04-09. They should be
stringified as C"<2019-04-08J00:00:00"> and C<"2019-04-09J00:00:00"> with
a "J", yet they are stringified as C"<2019-04-08T00:00:00"> and
C<"2019-04-09T00:00:00"> with a "T" in the 8 Fail reports.
A very useful tool to understand the problem is
http://analysis.cpantesters.org/solved?distv=DateTime-Event-Easter-1.08
This webpage computes the correlations between Fail / Pass and various
criteria. Of course, as we say, "correlation is not causation".
Actually, the saying should be "correlation is not always causation".
So a human mind must sift through all the listed criteria to find
significant correlations. A good candidate for real causation is the
correlation with the version of C<DateTime.pm>. Failure occurs with
versions 1.10, 1.18, 1.26, 1.36 and 1.42, while success occurs with
versions 1.48, 1.50 and 1.51.
So I have written this MWE:
use v5.10;
use strict;
use warnings;
use DateTime;
use DateTime::Calendar::Julian;
say $DateTime::VERSION;
say $DateTime::Calendar::Julian::VERSION;
my $dj = DateTime::Calendar::Julian->new(year => 2019, month => 10, day => 11);
say "method ", $dj->datetime;
say "stringified $dj";
I have two ready environments with C<DateTime.pm> versions 1.42 and 1.51.
In both versions, the result of the C<datetime> method was
C<'2019-10-11J00:00:00'>, which is correct, but the result of the
stringification was wrong with 1.42: C<'2019-10-11T00:00:00'>
(and correct with version 1.51).
The conclusion is that the problem in F<t/08as_span.t> is a
compatibility issue between C<DT::C::Julian> and C<DateTime.pm>. This
issue was fixed in some version between 1.42 and 1.48. But it still
lingers in Perl environments using an older C<DateTime.pm> version.
So, for the next release, I will use an explicit call to the
C<datetime> method instead of stringification in F<t/08as_span.t>.
And fix a typo: "result" instead of the nearly-French "resultat".
Also, I will require version 0.04 or later for
C<DateTime::Calendar::Julian>, because in versions 0.03 and before, it
would still use a "T". But I do not think these minor changes deserve
an immediate release to CPAN. Already fixed on Github.