Doc #52642 [Asn->Csd]: You have mixed up two values in one of the tables

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: Assigned +Status: Closed Type: Documentation Problem Package: Date/time related PHP Version: 5.2.14 Assigned To: aharvey Block user comment: N New Comment: This bug has been fixed in the documentation's XML sources. Since the online and downloadable versions of the documentation need some time to get updated, we would like to ask you to be a bit patient. Thank you for the report, and for helping us make our documentation better. Previous Comments: ------------------------------------------------------------------------ [2010-08-20 07:45:07] aharvey@php.net Automatic comment from SVN on behalf of aharvey Revision: http://svn.php.net/viewvc/?view=revision&amp;revision=302528 Log: Fix doc bug #52642 (You have mixed up two values in one of the tables) by adding a note to the strptime() manual page explaining how OS dependent it is, suggesting date_parse_from_format() as an alternative, and refining the parameter descriptions. ------------------------------------------------------------------------ [2010-08-19 05:55:30] aharvey@php.net 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. ------------------------------------------------------------------------ [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