Skip Menu |

This queue is for tickets about the POSIX-strptime CPAN distribution.

Report information
The Basics
Id: 81383
Status: open
Priority: 0/
Queue: POSIX-strptime

People
Owner: Nobody in particular
Requestors: j.leffler [...] acm.org
Cc:
AdminCc:

Bug Information
Severity: Normal
Broken in:
  • 0.10
  • 0.11
Fixed in: (no value)



Subject: strptime for %F fails on Mac OS X - testing glibc extension format specifier
Running the cpanp install of POSIX::strptime for Perl 5.16.1 on Mac OS X 10.7.5, I get the test failure: Failed 1/1 subtests # Failed test '2005-02-04 10:32:34 +0100|%F %T %z|34 32 10 4 1 105' # at t/POSIX-strptime.t line 21. # Structures begin differing at: # $got->[2] = '1' # $expected->[2] = '10' # Looks like you failed 1 test of 6. t/POSIX-strptime.t .. Dubious, test returned 1 (wstat 256, 0x100) Failed 1/6 subtests Looking at the POSIX specification of strptime (http://pubs.opengroup.org/onlinepubs/9699919799/functions/strptime.html), '%F' is not a POSIX standard format specifier. Looking at the Linux man page for strptime (http://linux.die.net/man/3/strptime), I see: --------- Glibc Notes For reasons of symmetry, glibc tries to support for strptime() the same format characters as for strftime(3). (In most cases the corresponding fields are parsed, but no field in tm is changed.) This leads to %F Equivalent to %Y-%m-%d, the ISO 8601 date format. --------- There are also some other glibc-specific extensions to strptime listed there. I'm not sure how you'll want to fix this. It would obviously be simple just to delete this test. Alternatively, you might decide to only run it when you're using glibc, or only report it as a problem if you're using glibc. That, though, raises the question of how you know you're dealing with glibc. I've installed the module; it'll do fine for me as it is. This is more along the lines of a heads up. -- Jonathan Leffler <jleffler@earthlink.net> <jleffler@us.ibm.com> Guardian of DBD::Informix 2011.0612 -- see http://dbi.perl.org/ "I don't suffer from insanity - I enjoy every minute of it!"
I'm seeing similar things with %z on Mac OS X. There, it does change the return results, but it looks like it is pretty buggy (or Mac OS X runs on a different clock ): Show quoted text
11> strptime('2005-02-04 10:32:34 UTC','%F %T %Z')
$res[5] = [ 34, 32, 10, 4, 1, 105, undef, undef ] Now, try UTC using %z Show quoted text
12> strptime('2005-02-04 10:32:34 +0000','%F %T %z')
$res[6] = [ 34, 32, 5, 4, 1, 105, 5, 34 ] Whoops! 10 o'clock is now 5 o'clock and we're now 5 hours west of UTC +0000. It might be local time, but I'm actually 4 hours west of UTC +0000: % date Wed Jul 17 16:28:10 EDT 2013 % TZ=UTC date Wed Jul 17 20:28:51 UTC 2013 So, I'd recommend not checking any of the non-standard format codes, as it seems to be the Wild Wild West out there!
I see the same problem with %F on FreeBSD 9.2 and 10.1 with the latest release 0.12 (various perl versions): # Failed test '1899-04-15|%F|undef undef undef 15 3 -1' # at t/POSIX-strptime.t line 24. # Structures begin differing at: # $got->[3] = undef # $expected->[3] = '15' # Failed test '1707-04-15|%F|undef undef undef 15 3 -193' # at t/POSIX-strptime.t line 24. # Structures begin differing at: # $got->[3] = undef # $expected->[3] = '15' # Looks like you failed 2 tests of 8. t/POSIX-strptime.t .. Dubious, test returned 2 (wstat 512, 0x200) Failed 2/8 subtests On 2012-11-23 11:58:23, JOHNL wrote: Show quoted text
> Running the cpanp install of POSIX::strptime for Perl 5.16.1 on Mac OS X > 10.7.5, I get the test failure: > > Failed 1/1 subtests > > # Failed test '2005-02-04 10:32:34 +0100|%F %T %z|34 32 10 4 1 105' > # at t/POSIX-strptime.t line 21. > # Structures begin differing at: > # $got->[2] = '1' > # $expected->[2] = '10' > # Looks like you failed 1 test of 6. > t/POSIX-strptime.t .. > Dubious, test returned 1 (wstat 256, 0x100) > Failed 1/6 subtests > > Looking at the POSIX specification of strptime > (http://pubs.opengroup.org/onlinepubs/9699919799/functions/strptime.html), > '%F' is not a POSIX standard format specifier. > > Looking at the Linux man page for strptime > (http://linux.die.net/man/3/strptime), I see: > > --------- > Glibc Notes > > For reasons of symmetry, glibc tries to support for strptime() the same > format characters as for strftime(3). (In most cases the corresponding > fields are parsed, but no field in tm is changed.) This leads to > %F > > Equivalent to %Y-%m-%d, the ISO 8601 date format. > --------- > > There are also some other glibc-specific extensions to strptime listed > there. > > I'm not sure how you'll want to fix this. It would obviously be simple > just to delete this test. Alternatively, you might decide to only run > it when you're using glibc, or only report it as a problem if you're > using glibc. That, though, raises the question of how you know you're > dealing with glibc. > > I've installed the module; it'll do fine for me as it is. This is more > along the lines of a heads up.
It also fails on solaris 10, with different test output: # Failed test '1899-04-15|%F|undef undef undef 15 3 -1' # at t/POSIX-strptime.t line 24. # Structures begin differing at: # $got->[3] = '0' # $expected->[3] = '15' # Failed test '1707-04-15|%F|undef undef undef 15 3 -193' # at t/POSIX-strptime.t line 24. # Structures begin differing at: # $got->[3] = '0' # $expected->[3] = '15' # Failed test '2005-02-04 10:32:34 UTC|%F %T %Z|34 32 10 4 1 105' # at t/POSIX-strptime.t line 24. # Structures begin differing at: # $got->[0] = '0' # $expected->[0] = '34' # Failed test '2005-02-04 10:32:34 +0100|%F %T %z|34 32 10 4 1 105' # at t/POSIX-strptime.t line 24. # Structures begin differing at: # $got->[0] = '0' # $expected->[0] = '34' # Failed test '2005-02-04|%F|undef undef undef 4 1 105' # at t/POSIX-strptime.t line 24. # Structures begin differing at: # $got->[3] = '0' # $expected->[3] = '4' # Looks like you failed 5 tests of 8. t/POSIX-strptime.t .. Dubious, test returned 5 (wstat 1280, 0x500) Failed 5/8 subtests On 2015-11-10 15:11:02, SREZIC wrote: Show quoted text
> I see the same problem with %F on FreeBSD 9.2 and 10.1 with the latest > release 0.12 (various perl versions): > > # Failed test '1899-04-15|%F|undef undef undef 15 3 -1' > # at t/POSIX-strptime.t line 24. > # Structures begin differing at: > # $got->[3] = undef > # $expected->[3] = '15' > > # Failed test '1707-04-15|%F|undef undef undef 15 3 -193' > # at t/POSIX-strptime.t line 24. > # Structures begin differing at: > # $got->[3] = undef > # $expected->[3] = '15' > # Looks like you failed 2 tests of 8. > t/POSIX-strptime.t .. > Dubious, test returned 2 (wstat 512, 0x200) > Failed 2/8 subtests > > > On 2012-11-23 11:58:23, JOHNL wrote:
> > Running the cpanp install of POSIX::strptime for Perl 5.16.1 on Mac > > OS X > > 10.7.5, I get the test failure: > > > > Failed 1/1 subtests > > > > # Failed test '2005-02-04 10:32:34 +0100|%F %T %z|34 32 10 4 1 105' > > # at t/POSIX-strptime.t line 21. > > # Structures begin differing at: > > # $got->[2] = '1' > > # $expected->[2] = '10' > > # Looks like you failed 1 test of 6. > > t/POSIX-strptime.t .. > > Dubious, test returned 1 (wstat 256, 0x100) > > Failed 1/6 subtests > > > > Looking at the POSIX specification of strptime > > (http://pubs.opengroup.org/onlinepubs/9699919799/functions/strptime.html), > > '%F' is not a POSIX standard format specifier. > > > > Looking at the Linux man page for strptime > > (http://linux.die.net/man/3/strptime), I see: > > > > --------- > > Glibc Notes > > > > For reasons of symmetry, glibc tries to support for strptime() the > > same > > format characters as for strftime(3). (In most cases the > > corresponding > > fields are parsed, but no field in tm is changed.) This leads to > > %F > > > > Equivalent to %Y-%m-%d, the ISO 8601 date format. > > --------- > > > > There are also some other glibc-specific extensions to strptime > > listed > > there. > > > > I'm not sure how you'll want to fix this. It would obviously be > > simple > > just to delete this test. Alternatively, you might decide to only > > run > > it when you're using glibc, or only report it as a problem if you're > > using glibc. That, though, raises the question of how you know > > you're > > dealing with glibc. > > > > I've installed the module; it'll do fine for me as it is. This is > > more > > along the lines of a heads up.