I took a look at your module. Trying to compile the dzil authordep
"Dist::Zilla::PluginBundle::BAREFOOT, I got this error:
t/tdist.t .... couldn't determine document name for lib/Test/Module.pm
Add something like this to lib/Test/Module.pm:
# PODNAME: bobby_tables.pl at
/home/jmaslak/perl5/perlbrew/perls/perl-5.22.1/lib/site_perl/5.22.1/Pod/Weaver.pm
line 135.
t/tdist.t .... 1/?
# Failed test 'command succeeded [dzil build]'
# at t/tdist.t line 79.
# got: '65280'
# expected: '0'
# Looks like you failed 1 test of 1.
t/tdist.t .... Dubious, test returned 1 (wstat 256, 0x100)
Failed 1/1 subtests
That said, once I built it (after adding the line Pod::Weaver wanted) I was
able to dzil build / dzil test your module that I cloned from git.
I got a ton of errors for my America/Denver time zone.
if I set my timezone to Los Angeles, I only got three failures (MUCH
better), all for the same date:
# Failed test 'successful parse: 04/95 00:22:12 PDT'
# at t/date-parse.t line 123.
# got: '1995-03-31'
# expected: '1995-04-01'
Of course April 1, 1995 was not yet daylight savings time, so 22 minutes
after midnight PDT would be 38 minutes *before* midnight PST, which
America/Pacific would use for time display.
I'd suggest you set $ENV{TZ} in your test scripts to a known time zone to
do these comparisons. I suspect some system somewhere also mis-handles
when DST starts (it didn't always start when it starts now, at least in the
USA).
I suspect your issue is a combination of OS (possibly how up to date it is
as well) and timezone.
On Mon, Mar 28, 2016 at 9:15 PM, Buddy Burden <barefootco...@gmail.com>
wrote:
> Jim,
>
> Are you familiar with http://matrix.cpantesters.org/?dist=Date-Easy?
>>
>
> Sure.
>
> The fact that your other CPAN distributions are shown in the matrix as
>> mostly PASSing -- see http://matrix.cpantesters.org/?author=BAREFOOT --
>> suggests that there are real problems with Date-Easy.
>>
>
> Oh, absolutely: I know there's a real problem, and I know exactly where it
> is in the code, and I have a _rough_ idea of how to fix it. The problem
> is, the problem doesn't show up on every system: only about 85% of them.
> My personal system just happens to be in the 15%. :-(
>
> So I want to be able to build a Perl that is in the 85%, and then I can
> fix the problem pretty easily.[1] Without that, the only way I can see if
> my code works is to release a new version to CPAN every time and then wait
> to see what the smokers throw up. That's a pretty slow dev cycle. :-) So
> that's what I'm trying to avoid.
>
> The challenge is to be able to identify exactly which aspect of a system
> causes it to be in the 85% vs the 15%. Admittedly the config_args thing
> was a wild guess that just happened to show some correlation with the
> problem.
>
> My own hunch is
>> that these problems have little or nothing to do with whether
>> 'config_args' is populated or not.
>>
>
> As is Tony's. I'm still looking. Going to try Curtis' suggestion next.
>
> On the plus side, I'm really souping up Tobyink's `cpan-testers`
> script.[2] :-) So I'll toss out my modified version once I finish with
> that and hopefully it can be useful to other folks as well.
>
>
> -- Buddy
>
>
> [1] Assuming of course that the problem is caused by a particular build as
> opposed to something I can't control for, like, say, a certain OS. But I'm
> _fairly_ sure that that is the case.
> [2] http://www.perlmonks.org/?node_id=978606
>
