Doc #52642 [Opn->Asn]: You have mixed up two values in one of the tables
| From: | aharvey@php.net | Date: | Thu, 19 Aug 2010 03:55:31 +0000 |
| Subject: | Doc #52642 [Opn->Asn]: You have mixed up two values in one of the tables | ||
| References: | 1 | Groups: | php.doc.bugs |
| Request: | Send a blank email to doc-bugs+get-4889@lists.php.net to get a copy of this message | ||
Edit report at http://bugs.php.net/bug.php?id=52642&edit=1
ID: 52642
Updated by: aharvey@php.net
Reported by: superspring+php at gmail dot com
Summary: You have mixed up two values in one of the tables
-Status: Open
+Status: Assigned
Type: Documentation Problem
Package: Date/time related
PHP Version: 5.2.14
-Assigned To:
+Assigned To: aharvey
Block user comment: N
New Comment:
Firstly, %p and %P are the right way around, even if it seems
counterintuitive -- that's the way they're specified for C's strftime()
function, and strptime() is supposed to accept the same format.
That said, PHP is basically beholden to whatever the underlying C
strptime() function does, and that means PHP inherits its bugs, too. On
Linux, strptime() just doesn't handle %P at all, so that will always
return false, and it doesn't seem to do the right thing with %p either.
I'll see if I can come up with a way of making it clearer in the manual
that strptime() is heavily platform-dependent and doesn't tend to accept
the same range of format parameters as strftime(). Honestly, in the
longer term, we should probably consider deprecating strptime() in
favour of date_parse_from_format() or reimplement it as a wrapper around
that function.
Previous Comments:
------------------------------------------------------------------------
[2010-08-19 04:36:19] superspring+php at gmail dot com
Description:
------------
%p UPPER-CASE 'AM' or 'PM' based on the given time
%P lower-case 'am' or 'pm' based on the given time
These lines appear to be the wrong way around.
<?php
$date = '15/02/08 11:19:56 am';
$dateFormat1 = '%d/%m/%y %l:%M:%S %p'; // Little P, which docs say is
upper-case
$dateFormat2 = '%d/%m/%y %l:%M:%S %P'; // Big P, which docs say is
lower-case
echo strptime($date, $dateFormat1) == true ? "true\n" : "false\n";
echo strptime($date, $dateFormat2) == true ? "true\n" : "false\n";
Result is true, false, which means that %p is matching, but docs say it
will
only match on upper case, which is wrong and that %P is not matching,
but docs
say it will with the lower case.
Since the input has a lower case 'am' in it, the lower-case %P should
match, but
it does not.
Test script:
---------------
<?php
$date = '15/02/08 11:19:56 am';
$dateFormat1 = '%d/%m/%y %l:%M:%S %p'; // Little P, which docs say is
upper-case
$dateFormat2 = '%d/%m/%y %l:%M:%S %P'; // Big P, which docs say is
lower-case
echo strptime($date, $dateFormat1) == true ? "true\n" : "false\n";
echo strptime($date, $dateFormat2) == true ? "true\n" : "false\n";
Result is true, false, which means that %p is matching, but docs say it
will only match on upper case, which is wrong and that %P is not
matching, but docs say it will with the lower case.
Since the input has a lower case 'am' in it, the lower-case %P should
match, but it does not.
Expected result:
----------------
false
true
Actual result:
--------------
true
false
------------------------------------------------------------------------
--
Edit this bug report at http://bugs.php.net/bug.php?id=52642&edit=1