t/date_construct.t: Can fail in certain installations

[jkeenan]

I am in the process of assessing the perl-5.28.0-readiness of CPAN modules upon which other CPAN modules depend -- the so-called "high upstream on the CPAN river" modules.

Today I tested XML::Atom::SimpleFeed against perl-5.27.11 on a FreeBSD-11.1 virtual machine sitting on a FreeBSD-11.9 host. I got the following test failures.

$ this_prove -vb t/date_construct.t 
t/date_construct.t .. 
ok 1 - correct RFC 3339 for Unix times
ok 2 - correct RFC 3339 for Time::Piece objects
ok 3 - ... regardless of local timezone
Cannot determine local time zone
# Tests were run but no plan was declared and done_testing() was not seen.
# Looks like your test exited with 2 just after 3.
Dubious, test returned 2 (wstat 512, 0x200)
All 3 subtests passed 

Test Summary Report
-------------------
t/date_construct.t (Wstat: 512 Tests: 3 Failed: 0)
  Non-zero exit status: 2
  Parse errors: No plan found in TAP output
Files=1, Tests=3,  0 wallclock secs ( 0.02 usr  0.03 sys +  0.27 cusr  0.04 csys =  0.35 CPU)
Result: FAIL

Such failures have a dual impact: They prevent installers like cpan from installing XML-Atom-SimpleFeed's reverse dependencies, and they prevent those reverse dependencies from being reached during automated CPANtesters processes based on dependency order.

Granted, this failure does not occur in all environments. But this failure has also appeared in Dist::Zilla in the same environment (rjbs/Dist-Zilla#622). I will submit a p.r. which provides a simple workaround. Please evaluate it, apply it and issue a new CPAN release so that your distribution is perl-5.28.0-ready.

Thank you very much.
Jim Keenan

[ap]

This doesn’t have anything to do with 5.28. I get the same failure on my macOS 10.12.6 machine in my 5.24.3.

[ap]

Does doing export TZ=Etc/GMT in the shell before running the tests make it work for you?

[ap]

Never mind, and no worries about never answering, since that was a silly question in the first place.

I was asking about Etc/GMT because ① I am not convinced that any specific hardcoded timezone is guaranteed to always exist in an installation. If it doesn’t, we’d get this spurious failure yet again, despite the fix, so the ”fix” would just be treading water.

But I thought about what the test is trying to accomplish and realised that the whole thing was silly. The point of the test is to check what happens if the datetimey object passed to X:A:SF has a timezone attached, rather than being in UTC. For that to work and make sense, ② the datetimey object must have a timezone attached and ③ the timezone must be something other than UTC.

Most commonly in actual use of the module this timezone will be whatever the local timezone is, hence asking DateTime for that makes the most sense.

So where does that leave us when that fails? The combination of ① ② and ③ basically means that nothing other than a skip makes sense. Everything else is monkey business: it makes the test not fail, but it also means that the test is successfully testing nothing useful, which is worse than not having a test. Hence, a skip is the only reasonable response in that circumstance.