From @eserte

The t/011_nanosecond.t of DateTime-Format-CLDR-1.19 test started to
fail at some point between 5.27.8 and 5.27.9. I can reproduce the
failure on all my Linux smokers, but not on my FreeBSD smokers.

Test log:

# Failed test 'Pattern: 'dd.MM.yyy HH:mm:ss.SSSSSSSSSSSSSS'
# String: '01.01.2000 01:10:20.00000000999999'
# Original: '2000-01-01T01:10:20.10 floating'
# Computed: '2000-01-01T01:10:20.9 floating'
# Locale: 'en-US''
# at t/lib/testlib.pm line 34.

# Failed test 'Pattern: 'dd.MM.yyy HH:mm:ss.SSSSSSSSSSSSSS'
# String: '01.01.2000 03:10:20.00000099999999'
# Original: '2000-01-01T03:10:20.1000 floating'
# Computed: '2000-01-01T03:10:20.999 floating'
# Locale: 'en-US''
# at t/lib/testlib.pm line 34.

# Failed test 'Pattern: 'dd.MM.yyy HH:mm:ss.SSSSSSSSSSSSSS'
# String: '01.01.2000 04:10:20.00000999999999'
# Original: '2000-01-01T04:10:20.10000 floating'
# Computed: '2000-01-01T04:10:20.9999 floating'
# Locale: 'en-US''
# at t/lib/testlib.pm line 34.
# Looks like you failed 3 tests of 13.
t/011_nanosecond.t ....
Dubious, test returned 3 (wstat 768, 0x300)
Failed 3/13 subtests

Flags:
category=core
severity=low
---
Site configuration information for perl 5.27.9:

Configured by eserte at Tue Feb 20 21:59:42 CET 2018.

Summary of my perl5 (revision 5 version 27 subversion 9) configuration:

Platform:
osname=linux
osvers=3.16.0-4-amd64
archname=x86_64-linux
uname='linux cabulja 3.16.0-4-amd64 #1 smp debian 3.16.51-3 (2017-12-13) x86_64 gnulinux '
config_args='-ds -e -Dprefix=/opt/perl-5.27.9 -Dusedevel -Dusemallocwrap=no -Dcf_email=srezic@cpan.org'
hint=recommended
useposix=true
d_sigaction=define
useithreads=undef
usemultiplicity=undef
use64bitint=define
use64bitall=define
uselongdouble=undef
usemymalloc=n
default_inc_excludes_dot=define
bincompat5005=undef
Compiler:
cc='cc'
ccflags ='-fwrapv -fno-strict-aliasing -pipe -fstack-protector-strong -I/usr/local/include -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -D_FORTIFY_SOURCE=2'
optimize='-O2'
cppflags='-fwrapv -fno-strict-aliasing -pipe -fstack-protector-strong -I/usr/local/include'
ccversion=''
gccversion='4.9.2'
gccosandvers=''
intsize=4
longsize=8
ptrsize=8
doublesize=8
byteorder=12345678
doublekind=3
d_longlong=define
longlongsize=8
d_longdbl=define
longdblsize=16
longdblkind=3
ivtype='long'
ivsize=8
nvtype='double'
nvsize=8
Off_t='off_t'
lseeksize=8
alignbytes=8
prototype=define
Linker and Libraries:
ld='cc'
ldflags =' -fstack-protector-strong -L/usr/local/lib'
libpth=/usr/local/lib /usr/lib/gcc/x86_64-linux-gnu/4.9/include-fixed /usr/include/x86_64-linux-gnu /usr/lib /lib/x86_64-linux-gnu /lib/../lib /usr/lib/x86_64-linux-gnu /usr/lib/../lib /lib
libs=-lpthread -lnsl -lgdbm -ldb -ldl -lm -lcrypt -lutil -lc -lgdbm_compat
perllibs=-lpthread -lnsl -ldl -lm -lcrypt -lutil -lc
libc=libc-2.19.so
so=so
useshrplib=false
libperl=libperl.a
gnulibc_version='2.19'
Dynamic Linking:
dlsrc=dl_dlopen.xs
dlext=so
d_dlsymun=undef
ccdlflags='-Wl,-E'
cccdlflags='-fPIC'
lddlflags='-shared -O2 -L/usr/local/lib -fstack-protector-strong'


---
@INC for perl 5.27.9:
/opt/perl-5.27.9/lib/site_perl/5.27.9/x86_64-linux
/opt/perl-5.27.9/lib/site_perl/5.27.9
/opt/perl-5.27.9/lib/5.27.9/x86_64-linux
/opt/perl-5.27.9/lib/5.27.9

---
Environment for perl 5.27.9:
HOME=/home/eserte
LANG=en_US.UTF-8
LANGUAGE (unset)
LD_LIBRARY_PATH (unset)
LOGDIR (unset)
PATH=/usr/local/bin:/usr/bin:/bin:/usr/local/sbin:/usr/sbin:/sbin:/home/eserte/bin/linux-gnu:/home/eserte/bin/sh:/home/eserte/bin:/home/eserte/bin/pistachio-perl/bin:/usr/games:/home/eserte/devel
PERLDOC=-MPod::Perldoc::ToTextOverstrike
PERL_BADLANG (unset)
SHELL=/bin/zsh

From @eserte

Looked into my fail report list again, and it seems that the same error may happen also with older perl versions. And the author has already put a note in the test script​:

  explain("This test might fail on some plattforms due to unknown reasons");

From zefram@fysh.org

slaven@​rezic.de wrote​:

The t/011_nanosecond.t of DateTime-Format-CLDR-1.19 test started to
fail at some point between 5.27.8 and 5.27.9.

Fails for me in that manner on both 5.27.8 and 5.27.9. On my test perls,
it fails in this manner on all perls from 5.21.4 onwards. So this
doesn't look like a current BBC.

On older perls I see it failing on some versions and passing on other
versions in a really unusual pattern, which makes me suspect that it
actually depends on which version of some other module is installed,
perhaps DateTime​::Locale. (DT​:F​:CLDR is failing where there's a new
DT​:L and succeeding where there's an old one. I have an old DT​:L
on some versions because the new DT​:L's deps have porting problems.)
But there's also some dependence on the floating point format​: prior to
5.21.4 I only see the failures on nvtype=double builds, while it succeeds
on nvtype=long double builds regardless of the versions of other modules.
(The failures from 5.21.4 happen regardless of nvtype.)

I'll look some more.

-zefram

The RT System itself - Status changed from 'new' to 'open'

From @eserte

Dana Wed, 21 Feb 2018 13​:44​:48 -0800, zefram@​fysh.org reÄ�e​:

slaven@​rezic.de wrote​:

The t/011_nanosecond.t of DateTime-Format-CLDR-1.19 test started to
fail at some point between 5.27.8 and 5.27.9.

Fails for me in that manner on both 5.27.8 and 5.27.9. On my test perls,
it fails in this manner on all perls from 5.21.4 onwards. So this
doesn't look like a current BBC.

On older perls I see it failing on some versions and passing on other
versions in a really unusual pattern, which makes me suspect that it
actually depends on which version of some other module is installed,
perhaps DateTime​::Locale.

Does not seem so --- I run the test script with Module​::PrintUsed on the failing linux and passing freebsd system, and the only difference is​:

  - Test​::NoWarnings 1.04
  - Test​::NoWarnings​::Warning 1.04
  - Test2​::API 1.302122
+ - Test2​::API​::Breakage 1.302122
  - Test2​::API​::Context 1.302122
  - Test2​::API​::Instance 1.302122
  - Test2​::API​::Stack 1.302122

... which is expected, as Test2​::API​::Breakage is loaded only if a failure occurs.

(DT​:F​:CLDR is failing where there's a new
DT​:L and succeeding where there's an old one. I have an old DT​:L
on some versions because the new DT​:L's deps have porting problems.)
But there's also some dependence on the floating point format​: prior to
5.21.4 I only see the failures on nvtype=double builds, while it succeeds
on nvtype=long double builds regardless of the versions of other modules.
(The failures from 5.21.4 happen regardless of nvtype.)

I'll look some more.

-zefram

From maros@cpan.org

Might be related to houseabsolute/DateTime.pm#29

From zefram@fysh.org

The Perl version difference that I see between 5.21.3 and
5.21.4 (on Linux with nvtype=long double) bisects to commit
8a00edd "POSIX math​: have the Perl_func
wrappers for the C89 math, too.", which changes some POSIX functions
to use the long-double versions of C functions on long-double builds.
This goes some way to explaining the nvtype difference that I see on
older perls. It also hints that the OS difference that Slaven sees
might be due to libc differences in these math functions.

The perl version differences that I see on older perls (on Linux
with nvtype=double) still look likely to be due to module versions.
There's clearly more than one factor at work.

-zefram

From @eserte

Dana Thu, 22 Feb 2018 11​:23​:24 -0800, zefram@​fysh.org reÄ�e​:

The Perl version difference that I see between 5.21.3 and
5.21.4 (on Linux with nvtype=long double) bisects to commit
8a00edd "POSIX math​: have the Perl_func
wrappers for the C89 math, too.", which changes some POSIX functions
to use the long-double versions of C functions on long-double builds.
This goes some way to explaining the nvtype difference that I see on
older perls. It also hints that the OS difference that Slaven sees
might be due to libc differences in these math functions.

The perl version differences that I see on older perls (on Linux
with nvtype=double) still look likely to be due to module versions.
There's clearly more than one factor at work.

Link to CPAN RT ticket​: https://rt.cpan.org/Ticket/Display.html?id=124691

This was reported as a BBC ticket but we appear to have not made a decision to change anything in perl for 5.28.0's final release. Given this has been reported upstream, I propose we close this unless we can identify a bug in Perl that needs to be addressed.

This was reported as a BBC ticket but we appear to have not made a decision to change anything in perl for 5.28.0's final release. Given this has been reported upstream, I propose we close this unless we can identify a bug in Perl that needs to be addressed.

See houseabsolute/DateTime.pm#29 (comment) for more analysis. It appears that @autarch spotted this problem in @maros 's distro several years ago.

I have two inferences. First, this is a problem likely to occur only with certain configurations of perl. I've demonstrated it with -Dusequadmath and I suspect we could also do that with -Duselongdouble.

Second, this is a problem which will have to be addressed first by the CPAN module author. The failing test needs to be made more flexible to accommodate rounding errors with different perl configurations. Note that that may not be the entire problem, but it's definitely part of the problem.

I hope we hear back from the module author and from Dave Rolsky.

Thank you very much.
Jim Keenan

@autarch

This seems like a bug in the module (DT::F::CLDR), not the perl core.

This seems like a bug in the module (DT::F::CLDR), not the perl core.

Agreed. I cloned the github repo, intending to prepare a p.r. along the same lines as the one you applied to DateTime in v1.51 (houseabsolute/DateTime.pm#89). However, right out-of-the-box I got a Module::Install-related failure in Makefile.PL, reported in houseabsolute/DateTime.pm#89.

I think the core has made every reasonable effort to address this issue and that it will be up to the module author to take the next step. So I'm closing it as a core issue.

Thank you very much.
Jim Keenan

I think your second link was meant to be: https://rt.cpan.org/Public/Bug/Display.html?id=131908