[PHP-BUG] Bug #55308 [NEW]: pathinfo() options parameter not as expected
From:
Operating system:
PHP version: 5.3.6
Package: *Directory/Filesystem functions
Bug Type: Bug
Bug description:pathinfo() options parameter not as expected
Description:
The options parameter of pathinfo() does not seem to operate according to
the description in the manual, nor as might be expected. The manual
description implies that if an options value consisting of more than one of
the bitwise PATHINFO_* constants is supplied, the return value will be a
string consisting of all the parts requested; however, this is not the case
-- only the part corresponding to the lowest bit is returned.
This seems both contrary to the documentation and completely illogical.
It would be much better if pathinfo returned an array of the requested
elements, *except* when a single element is requested. If this is deemed
not possible due to BC, either the behaviour or the documentation should be
fixed so that they match!
Test script:
---
Expected result:
EITHER:
array(2) {
["extension"]=>
string(3) "ext"
["filename"]=>
string(4) "file"
}
OR:
string(8) "file.ext"
Actual result:
--
string(3) "ext"
--
Edit bug report at https://bugs.php.net/bug.php?id=55308&edit=1
--
Try a snapshot (PHP 5.4):
https://bugs.php.net/fix.php?id=55308&r=trysnapshot54
Try a snapshot (PHP 5.3):
https://bugs.php.net/fix.php?id=55308&r=trysnapshot53
Try a snapshot (trunk):
https://bugs.php.net/fix.php?id=55308&r=trysnapshottrunk
Fixed in SVN:
https://bugs.php.net/fix.php?id=55308&r=fixed
Fixed in SVN and need be documented:
https://bugs.php.net/fix.php?id=55308&r=needdocs
Fixed in release:
https://bugs.php.net/fix.php?id=55308&r=alreadyfixed
Need backtrace:
https://bugs.php.net/fix.php?id=55308&r=needtrace
Need Reproduce Script:
https://bugs.php.net/fix.php?id=55308&r=needscript
Try newer version:
https://bugs.php.net/fix.php?id=55308&r=oldversion
Not developer issue:
https://bugs.php.net/fix.php?id=55308&r=support
Expected behavior:
https://bugs.php.net/fix.php?id=55308&r=notwrong
Not enough info:
https://bugs.php.net/fix.php?id=55308&r=notenoughinfo
Submitted twice:
https://bugs.php.net/fix.php?id=55308&r=submittedtwice
register_globals:
https://bugs.php.net/fix.php?id=55308&r=globals
PHP 4 support discontinued:
https://bugs.php.net/fix.php?id=55308&r=php4
Daylight Savings:https://bugs.php.net/fix.php?id=55308&r=dst
IIS Stability:
https://bugs.php.net/fix.php?id=55308&r=isapi
Install GNU Sed:
https://bugs.php.net/fix.php?id=55308&r=gnused
Floating point limitations:
https://bugs.php.net/fix.php?id=55308&r=float
No Zend Extensions:
https://bugs.php.net/fix.php?id=55308&r=nozend
MySQL Configuration Error:
https://bugs.php.net/fix.php?id=55308&r=mysqlcfg
#43452 [Com]: strtotime returns wrong date when requested day is same as first day of the mon
ID: 43452
Comment by: m dot ford at leedsmet dot ac dot uk
Reported By: sean dot thorne at gmail dot com
Status: Assigned
Bug Type: Date/time related
Operating System: Mac OS X 10.4.11
PHP Version: 5.2CVS-2007-11-29 (CVS)
Assigned To: derick
New Comment:
Then there's a doc problem, because currently http://php.net/strtotime
describes its first argument as "The string to parse, according to the
GNU ยป Date Input Formats syntax", with a link to the GNU documentation.
If strtotime() does not, in fact, implement the entirety of what's
described there, exactly as described, then what's actually implemented
should be incorporated into the PHP manual and that link removed.
Previous Comments:
[2008-07-15 17:23:37] [EMAIL PROTECTED]
Assigning this to myself, but be aware that we do not necessarily
implement this GNU date stuff -- we've never done this either. I'll
check it though.
--------
[2008-07-15 17:19:38] m dot ford at leedsmet dot ac dot uk
Derick, please take another look at this.
I've examined it in some depth, and tend to agree there's a bug here.
However, if you read the GNU Date Input Formats syntax, linked from
http://php.net/manual/function.strtotime.php, very closely, you find it
says:
"a day of the week will forward the date (only if necessary) to reach
that day of the week in the future"
... and ...
"a number may precede a day of the week item to move forward
supplementary weeks."
The crucial word here is "supplementary". Taken together, these
specifications suggest that, somewhat counter-intuitively:
Monday month year
should represent the first Monday of the month, no matter what date it
falls on, and
1 Monday month year
should be the Monday *after* that (i.e. the 2nd Monday!!), and so on.
Other wording in the GNU Date "Day of week items" section would tend to
confirm this interpretation.
I therefore submit that the bug actually manifests when the first
occurrence of the requested weekday falls on any date *other* than the
first of the month! :(
However you interpret it, it's nonetheless clear that the relationship
of "1 weekday" to "weekday" should be fixed -- either according to the
GNU specification to occur 1 week later, or more intuitively to mean the
same thing. It's definitely NOT right that "1 Monday" (for example)
means something different from "Monday" *only* when "Monday" is the 1st
of the month...!!
[2008-06-17 17:21:57] soapergem at gmail dot com
I also confirmed this. This is pretty serious, too! There are an
infinite number of examples in which you can reproduce it; here are a
few:
// expect 06-15-2008, get 06-22-2008
$date = strtotime('3 Sunday June 2008');
echo date('m-d-Y', $date);
// expect 07-08-2008, get 07-15-2008
$date = strtotime('2 Tuesday July 2008');
echo date('m-d-Y', $date);
// expect 08-22-2008, get 08-29-2008
$date = strtotime('4 Friday August 2008');
echo date('m-d-Y', $date);
// expect 09-29-2008, get 10-06-2008
$date = strtotime('5 Monday September 2008');
echo date('m-d-Y', $date);
// expect 10-01-2008, get 10-08-2008
$date = strtotime('1 Wednesday October 2008');
echo date('m-d-Y', $date);
Developers please take note: THIS IS A SERIOUS BUG! (and it's been
around for a long time)
[2008-04-02 14:06:23] billyt at claritytech dot com
We also wrote our own function that handles it. Although, it's purely
by random chance that we discovered the problem. It's not something we
would specifically have tested for. I wonder how many other people are
using it in production with no idea that it's a problem.
[2008-03-30 22:39:34] sean dot thorne at gmail dot com
I ended up writing a compensator for the problem, because it appears
that the PHP Dev crew has better things to do then clean up the code
base...
I kept it simple and grabbed what day was the the first of the month
and then found where Thursday would be in comparison and knew the third
thursday was just 3 times whatever the date of the first thursday.
The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at
http://bugs.php.net/43452
--
Edit this bug report at http://bugs.php.net/?id=43452&edit=1
#43452 [Com]: strtotime returns wrong date when requested day is same as first day of the mon
ID: 43452
Comment by: m dot ford at leedsmet dot ac dot uk
Reported By: sean dot thorne at gmail dot com
Status: Open
Bug Type: Date/time related
Operating System: Mac OS X 10.4.11
PHP Version: 5.2CVS-2007-11-29 (CVS)
New Comment:
Derick, please take another look at this.
I've examined it in some depth, and tend to agree there's a bug here.
However, if you read the GNU Date Input Formats syntax, linked from
http://php.net/manual/function.strtotime.php, very closely, you find it
says:
"a day of the week will forward the date (only if necessary) to reach
that day of the week in the future"
... and ...
"a number may precede a day of the week item to move forward
supplementary weeks."
The crucial word here is "supplementary". Taken together, these
specifications suggest that, somewhat counter-intuitively:
Monday month year
should represent the first Monday of the month, no matter what date it
falls on, and
1 Monday month year
should be the Monday *after* that (i.e. the 2nd Monday!!), and so on.
Other wording in the GNU Date "Day of week items" section would tend to
confirm this interpretation.
I therefore submit that the bug actually manifests when the first
occurrence of the requested weekday falls on any date *other* than the
first of the month! :(
However you interpret it, it's nonetheless clear that the relationship
of "1 weekday" to "weekday" should be fixed -- either according to the
GNU specification to occur 1 week later, or more intuitively to mean the
same thing. It's definitely NOT right that "1 Monday" (for example)
means something different from "Monday" *only* when "Monday" is the 1st
of the month...!!
Previous Comments:
[2008-06-17 17:21:57] soapergem at gmail dot com
I also confirmed this. This is pretty serious, too! There are an
infinite number of examples in which you can reproduce it; here are a
few:
// expect 06-15-2008, get 06-22-2008
$date = strtotime('3 Sunday June 2008');
echo date('m-d-Y', $date);
// expect 07-08-2008, get 07-15-2008
$date = strtotime('2 Tuesday July 2008');
echo date('m-d-Y', $date);
// expect 08-22-2008, get 08-29-2008
$date = strtotime('4 Friday August 2008');
echo date('m-d-Y', $date);
// expect 09-29-2008, get 10-06-2008
$date = strtotime('5 Monday September 2008');
echo date('m-d-Y', $date);
// expect 10-01-2008, get 10-08-2008
$date = strtotime('1 Wednesday October 2008');
echo date('m-d-Y', $date);
Developers please take note: THIS IS A SERIOUS BUG! (and it's been
around for a long time)
[2008-04-02 14:06:23] billyt at claritytech dot com
We also wrote our own function that handles it. Although, it's purely
by random chance that we discovered the problem. It's not something we
would specifically have tested for. I wonder how many other people are
using it in production with no idea that it's a problem.
[2008-03-30 22:39:34] sean dot thorne at gmail dot com
I ended up writing a compensator for the problem, because it appears
that the PHP Dev crew has better things to do then clean up the code
base...
I kept it simple and grabbed what day was the the first of the month
and then found where Thursday would be in comparison and knew the third
thursday was just 3 times whatever the date of the first thursday.
[2008-03-30 22:21:21] billyt at claritytech dot com
This is still a problem with 5.2.6RC4-dev!!!
This is causing us serious issues ... any ideas???
[2007-11-29 15:39:52] sean dot thorne at gmail dot com
Description:
When asking strtotime for the 3rd thursday in a month and the first day
of that month is thursday, it ignores the first thursday. It then begins
to count after that first Thursday and returns the fourth Thursday.
Reproduce code:
---
$day = strtotime("3 Thursday Nov 2007");
echo date("m-d-Y", $day);
Expected result:
11-15-2007
Actual result:
--
11-22-2007
--
Edit this bug report at http://bugs.php.net/?id=43452&edit=1
#29271 [Com]: behaviour of $string['text'] = 'new string';
ID: 29271
Comment by: m dot ford at leedsmet dot ac dot uk
Reported By: nospam0 at malkusch dot de
Status: Bogus
Bug Type: Strings related
Operating System: *
PHP Version: 5.0.0
New Comment:
Why should it? It's only deprecated, not obsolete -- and there's not
even a hint of a date being scheduled for its withdrawal.
(Deprecated meaning, roughly, not encouraged and may be withdrawn one
day, maybe, if the php gurus ever get around to it.)
As withdrawal of this feature hasn't been announced yet, I think you
can take it it'll probably be around at least for the lifetime of PHP 5
-- but the use of {} instead of [] is strongly encouraged.
Cheers!
Mike
Previous Comments:
[2004-07-28 13:49:59] nospam0 at malkusch dot de
> $string already IS a string and you still can use
> array-brackets to access a particular symbol
So PHP will never throw an error, even [] on strings is
deprecated since PHP4?
[2004-07-28 13:25:55] [EMAIL PROTECTED]
$string already IS a string and you still can use array-brackets to
access a particular symbol, so it won't become an array.
[2004-07-28 13:15:34] nospam0 at malkusch dot de
> It's expected behaviour: 'index' is casted to it's
> integer value (0), that's why you get this result.
But as I use $string[] and not $string{} it's undefined
wether it should be a new array or a string. So why
doesn't PHP throw an error?
[2004-07-28 12:39:59] [EMAIL PROTECTED]
Thank you for taking the time to write to us, but this is not
a bug. Please double-check the documentation available at
http://www.php.net/manual/ and the instructions on how to report
a bug at http://bugs.php.net/how-to-report.php
It's expected behaviour: 'index' is casted to it's integer value (0),
that's why you get this result.
[2004-07-20 01:54:22] nospam0 at malkusch dot de
Description:
$string = 'a bla';
$string['index'] = 'b blub';
does the same work as
$string = 'a bla';
$string{(int)'index'} = 'b blub'{0};
without any notic of undefined index or too long replacing
string. But it should throw any notice, because one could
expect that the code should produce a new Array('index' =>
'b blubb').
Reproduce code:
---
$string = 'a bla';
$string['index'] = 'b blub';
var_dump($string);
Expected result:
Either notices for use of deprecated [], undefined offset
'index' and too long replace char (and of course the
actual result)
or 'a bla' is deleted and $string has array('index' => 'b
blubb') as value.
Actual result:
--
string(5) "b bla"
--
Edit this bug report at http://bugs.php.net/?id=29271&edit=1
