[PHP-BUG] Bug #53299 [NEW]: strtotime expects date format to be MM/DD/YYYY even though timezone set to GMT
From: Operating system: CentOS 5.5 PHP version: 5.3.3 Package: Date/time related Bug Type: Bug Bug description:strtotime expects date format to be MM/DD/ even though timezone set to GMT Description: Using strtotime() to convert a UK date stamp (DD/MM/) but getting null or incorrect date. Test script: --- Expected result: 31st Aug 2010 Actual result: -- 1st Jan 1970 -- Edit bug report at http://bugs.php.net/bug.php?id=53299&edit=1 -- Try a snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=53299&r=trysnapshot52 Try a snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=53299&r=trysnapshot53 Try a snapshot (trunk): http://bugs.php.net/fix.php?id=53299&r=trysnapshottrunk Fixed in SVN: http://bugs.php.net/fix.php?id=53299&r=fixed Fixed in SVN and need be documented: http://bugs.php.net/fix.php?id=53299&r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=53299&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=53299&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=53299&r=needscript Try newer version: http://bugs.php.net/fix.php?id=53299&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=53299&r=support Expected behavior: http://bugs.php.net/fix.php?id=53299&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=53299&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=53299&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=53299&r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=53299&r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=53299&r=dst IIS Stability: http://bugs.php.net/fix.php?id=53299&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=53299&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=53299&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=53299&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=53299&r=mysqlcfg
Bug #52471 [Bgs]: Folders being treated as files when scandir() is used
Edit report at http://bugs.php.net/bug.php?id=52471&edit=1 ID: 52471 User updated by: d dot reade at ReadesGroupServices dot com Reported by: d dot reade at ReadesGroupServices dot com Summary:Folders being treated as files when scandir() is used Status: Bogus Type: Bug Package:Directory function related Operating System: CentOS 5.5 PHP Version:5.3.3 Block user comment: N New Comment: Sorry I see what you're saying - my bad! :( Previous Comments: [2010-07-28 16:17:17] degeb...@php.net You are *never* checking if something is a file. You are only checking if it's a directory. You are making the conclusion that if something is not a directory, then it must be a file. This conclusion is *incorrect*. For instance, there is the possibility that it doesn't even exist, which is the case here. [2010-07-28 16:14:22] d dot reade at ReadesGroupServices dot com I don't understand how it's my code? If you run the first example from the CWD, where "folderName" is located along with the test files/folders under "folderName", the results are that the test folders are actually files. The second example should be run from within the "folderName" folder, and this returns the correct results. The code in both examples is the same, the only difference is the folders we're scanning. [2010-07-28 16:09:20] degeb...@php.net Yes, I did. The bug is in your code, not in scandir() nor is_dir(). ------------------------ [2010-07-28 16:07:23] d dot reade at ReadesGroupServices dot com Did you try the test script? [2010-07-28 16:03:09] degeb...@php.net It just returns a string. The output should tell you why it's failing. In Example 1, neither of those exist in the current directory, and things that don't exist are naturally not directories. 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/bug.php?id=52471 -- Edit this bug report at http://bugs.php.net/bug.php?id=52471&edit=1
Bug #52471 [Bgs]: Folders being treated as files when scandir() is used
Edit report at http://bugs.php.net/bug.php?id=52471&edit=1 ID: 52471 User updated by: d dot reade at ReadesGroupServices dot com Reported by: d dot reade at ReadesGroupServices dot com Summary:Folders being treated as files when scandir() is used Status: Bogus Type: Bug Package:Directory function related Operating System: CentOS 5.5 PHP Version:5.3.3 Block user comment: N New Comment: I don't understand how it's my code? If you run the first example from the CWD, where "folderName" is located along with the test files/folders under "folderName", the results are that the test folders are actually files. The second example should be run from within the "folderName" folder, and this returns the correct results. The code in both examples is the same, the only difference is the folders we're scanning. Previous Comments: [2010-07-28 16:09:20] degeb...@php.net Yes, I did. The bug is in your code, not in scandir() nor is_dir(). ---------------- [2010-07-28 16:07:23] d dot reade at ReadesGroupServices dot com Did you try the test script? [2010-07-28 16:03:09] degeb...@php.net It just returns a string. The output should tell you why it's failing. In Example 1, neither of those exist in the current directory, and things that don't exist are naturally not directories. ---------------- [2010-07-28 15:33:03] d dot reade at ReadesGroupServices dot com Description: Using scandir() to fetch a list of folders/files in a folder. When I use foreach() and is_dir() to filter out folders from files, folders and files are being grouped together, almost like PHP thinks the folders are files. However if we use "." as the argument in the scandir() method, we get the desired results. The below test script assumes you've created the following folders/files: folderName/ folderName/testFolder1/ folderName/testFolder2/ folderName/testFile1 folderName/testFile2 These results occur using both the CLI and via a PHP page in the browser. Test script: --- Expected result: Example 2 gives the expected result: Folder: . Folder: .. File: testFile1 File: testFile2 Folder: testFolder1 Folder: testFolder2 Actual result: -- Example 1 gives the actual result: Folder: . Folder: .. File: testFile1 File: testFile2 File: testFolder1 File: testFolder2 -- Edit this bug report at http://bugs.php.net/bug.php?id=52471&edit=1
Bug #52471 [Bgs]: Folders being treated as files when scandir() is used
Edit report at http://bugs.php.net/bug.php?id=52471&edit=1 ID: 52471 User updated by: d dot reade at ReadesGroupServices dot com Reported by: d dot reade at ReadesGroupServices dot com Summary:Folders being treated as files when scandir() is used Status: Bogus Type: Bug Package:Directory function related Operating System: CentOS 5.5 PHP Version:5.3.3 Block user comment: N New Comment: Did you try the test script? Previous Comments: [2010-07-28 16:03:09] degeb...@php.net It just returns a string. The output should tell you why it's failing. In Example 1, neither of those exist in the current directory, and things that don't exist are naturally not directories. [2010-07-28 15:33:03] d dot reade at ReadesGroupServices dot com Description: Using scandir() to fetch a list of folders/files in a folder. When I use foreach() and is_dir() to filter out folders from files, folders and files are being grouped together, almost like PHP thinks the folders are files. However if we use "." as the argument in the scandir() method, we get the desired results. The below test script assumes you've created the following folders/files: folderName/ folderName/testFolder1/ folderName/testFolder2/ folderName/testFile1 folderName/testFile2 These results occur using both the CLI and via a PHP page in the browser. Test script: --- Expected result: Example 2 gives the expected result: Folder: . Folder: .. File: testFile1 File: testFile2 Folder: testFolder1 Folder: testFolder2 Actual result: -- Example 1 gives the actual result: Folder: . Folder: .. File: testFile1 File: testFile2 File: testFolder1 File: testFolder2 -- Edit this bug report at http://bugs.php.net/bug.php?id=52471&edit=1
[PHP-BUG] Bug #52471 [NEW]: Folders being treated as files when scandir() is used
From: Operating system: CentOS 5.5 PHP version: 5.3.3 Package: Directory function related Bug Type: Bug Bug description:Folders being treated as files when scandir() is used Description: Using scandir() to fetch a list of folders/files in a folder. When I use foreach() and is_dir() to filter out folders from files, folders and files are being grouped together, almost like PHP thinks the folders are files. However if we use "." as the argument in the scandir() method, we get the desired results. The below test script assumes you've created the following folders/files: folderName/ folderName/testFolder1/ folderName/testFolder2/ folderName/testFile1 folderName/testFile2 These results occur using both the CLI and via a PHP page in the browser. Test script: --- Expected result: Example 2 gives the expected result: Folder: . Folder: .. File: testFile1 File: testFile2 Folder: testFolder1 Folder: testFolder2 Actual result: -- Example 1 gives the actual result: Folder: . Folder: .. File: testFile1 File: testFile2 File: testFolder1 File: testFolder2 -- Edit bug report at http://bugs.php.net/bug.php?id=52471&edit=1 -- Try a snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=52471&r=trysnapshot52 Try a snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=52471&r=trysnapshot53 Try a snapshot (trunk): http://bugs.php.net/fix.php?id=52471&r=trysnapshottrunk Fixed in SVN: http://bugs.php.net/fix.php?id=52471&r=fixed Fixed in SVN and need be documented: http://bugs.php.net/fix.php?id=52471&r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=52471&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=52471&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=52471&r=needscript Try newer version: http://bugs.php.net/fix.php?id=52471&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=52471&r=support Expected behavior: http://bugs.php.net/fix.php?id=52471&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=52471&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=52471&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=52471&r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=52471&r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=52471&r=dst IIS Stability: http://bugs.php.net/fix.php?id=52471&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=52471&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=52471&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=52471&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=52471&r=mysqlcfg
Bug #52466 [Opn->Csd]: PHP cannot see filenames with spaces
Edit report at http://bugs.php.net/bug.php?id=52466&edit=1
ID: 52466
User updated by: d dot reade at ReadesGroupServices dot com
Reported by: d dot reade at ReadesGroupServices dot com
Summary:PHP cannot see filenames with spaces
-Status: Open
+Status: Closed
Type: Bug
Package:Filesystem function related
Operating System: CentOS 5.5
PHP Version:5.3.3
Block user comment: N
New Comment:
That's weird, it was doing it for me a second ago... and now it's not!!
Sorry to waste your time, but thanks anyway.
Previous Comments:
[2010-07-28 10:33:47] degeb...@php.net
Works fine for me using latest SVN 5.3 build:
dan...@daniel-laptop:~/tmp$ ls -l
total 24
-rw-r--r-- 1 daniel daniel 0 2010-07-28 10:30 foo bar.txt
-rw-r--r-- 1 daniel daniel 0 2010-07-28 10:30 helloworld.txt
dan...@daniel-laptop:~/tmp$ php -r 'var_dump(scandir("."));'
array(4) {
[0]=>
string(1) "."
[1]=>
string(2) ".."
[2]=>
string(11) "foo bar.txt"
[3]=>
string(14) "helloworld.txt"
}
------------------------
[2010-07-28 10:27:35] d dot reade at ReadesGroupServices dot com
Description:
Using the scandir() method to fetch a list of filenames in a folder.
Some filenames contain a space (via SSH this appears as "\ ", i.e.
"test\ file.txt"). However PHP sees this file as "test_file.txt". This
causes additional file operations such as file_exists() to return false.
Test script:
---
Expected result:
file.txt
test\ file.txt
Actual result:
--
file.txt
test_file.txt
--
Edit this bug report at http://bugs.php.net/bug.php?id=52466&edit=1
[PHP-BUG] Bug #52466 [NEW]: PHP cannot see filenames with spaces
From: Operating system: CentOS 5.5 PHP version: 5.3.3 Package: Filesystem function related Bug Type: Bug Bug description:PHP cannot see filenames with spaces Description: Using the scandir() method to fetch a list of filenames in a folder. Some filenames contain a space (via SSH this appears as "\ ", i.e. "test\ file.txt"). However PHP sees this file as "test_file.txt". This causes additional file operations such as file_exists() to return false. Test script: --- Expected result: file.txt test\ file.txt Actual result: -- file.txt test_file.txt -- Edit bug report at http://bugs.php.net/bug.php?id=52466&edit=1 -- Try a snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=52466&r=trysnapshot52 Try a snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=52466&r=trysnapshot53 Try a snapshot (trunk): http://bugs.php.net/fix.php?id=52466&r=trysnapshottrunk Fixed in SVN: http://bugs.php.net/fix.php?id=52466&r=fixed Fixed in SVN and need be documented: http://bugs.php.net/fix.php?id=52466&r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=52466&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=52466&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=52466&r=needscript Try newer version: http://bugs.php.net/fix.php?id=52466&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=52466&r=support Expected behavior: http://bugs.php.net/fix.php?id=52466&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=52466&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=52466&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=52466&r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=52466&r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=52466&r=dst IIS Stability: http://bugs.php.net/fix.php?id=52466&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=52466&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=52466&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=52466&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=52466&r=mysqlcfg
Bug #52031 [Bgs]: Passing "0" as a parameter through a custom method
Edit report at http://bugs.php.net/bug.php?id=52031&edit=1
ID: 52031
User updated by: d dot reade at ReadesGroupServices dot com
Reported by: d dot reade at ReadesGroupServices dot com
Summary: Passing "0" as a parameter through a custom method
Status: Bogus
Type: Bug
Package: Unknown/Other Function
Operating System: CentOS 5.5
PHP Version: 5.3.2
New Comment:
I see you what mean. Thanks for the clarification, much appreciated.
Previous Comments:
[2010-06-09 15:14:38] degeb...@php.net
You are comparing an integer with a string, so the string gets converted
to an int. Because (int)"Test" is (int)0 and 0==0, the condition
passes.
It's not a bug, and it's documented behavior. If you want it to check
the type as well, you need to use the === operator as documented.
--------
[2010-06-09 14:57:52] d dot reade at ReadesGroupServices dot com
Sorry but that makes no sense. How is this not a bug?
If I pass "0" as the parameter and the first if statement is empty(),
PHP knows the paramater is "empty" and the if statement is triggered.
Whereas without empty() PHP executes the first statement regardless even
though the same value would trigger empty()!
It shouldn't do that - if the first if statement is ($str == 'Test'),
PHP should skip it just as it would with any other string that doesn't
match.
[2010-06-09 14:51:46] degeb...@php.net
Sorry, but your problem does not imply a bug in PHP itself. For a
list of more appropriate places to ask for help using PHP, please
visit http://www.php.net/support.php as this bug system is not the
appropriate forum for asking support questions. Due to the volume
of reports we can not explain in detail here why your report is not
a bug. The support channels will be able to provide an explanation
for you.
Thank you for your interest in PHP.
See: http://php.net/manual/en/language.types.type-juggling.php
------------------------
[2010-06-09 14:41:32] d dot reade at ReadesGroupServices dot com
Description:
Sorry but I didn't know how to best word the summary.
I have a custom method with an if statement inside. If the parameter
passed through matches "Test", a string is echo'ed. However if I pass
"0" through as the parameter, PHP thinks this is "Test" and echoes the
string.
Passing a blank parameter through, i.e. "", does not have the same
effect as "0".
Inserting "if (empty($str))" before the if statement in the example
works as expected, catches the "0" parameter and I get the expected
result. However without this, I get the actual result.
All plugins have been disabled and Apache restarted.
Test script:
---
';
}
}
testMethod('Test');
testMethod(0);
testMethod();
testMethod(1);
testMethod('Something');
?>
Expected result:
Test String!
Actual result:
--
Test String!
Test String!
Test String!
--
Edit this bug report at http://bugs.php.net/bug.php?id=52031&edit=1
Bug #52031 [Bgs]: Passing "0" as a parameter through a custom method
Edit report at http://bugs.php.net/bug.php?id=52031&edit=1
ID: 52031
User updated by: d dot reade at ReadesGroupServices dot com
Reported by: d dot reade at ReadesGroupServices dot com
Summary: Passing "0" as a parameter through a custom method
Status: Bogus
Type: Bug
Package: Unknown/Other Function
Operating System: CentOS 5.5
PHP Version: 5.3.2
New Comment:
Sorry but that makes no sense. How is this not a bug?
If I pass "0" as the parameter and the first if statement is empty(),
PHP knows the paramater is "empty" and the if statement is triggered.
Whereas without empty() PHP executes the first statement regardless even
though the same value would trigger empty()!
It shouldn't do that - if the first if statement is ($str == 'Test'),
PHP should skip it just as it would with any other string that doesn't
match.
Previous Comments:
[2010-06-09 14:51:46] degeb...@php.net
Sorry, but your problem does not imply a bug in PHP itself. For a
list of more appropriate places to ask for help using PHP, please
visit http://www.php.net/support.php as this bug system is not the
appropriate forum for asking support questions. Due to the volume
of reports we can not explain in detail here why your report is not
a bug. The support channels will be able to provide an explanation
for you.
Thank you for your interest in PHP.
See: http://php.net/manual/en/language.types.type-juggling.php
------------
[2010-06-09 14:41:32] d dot reade at ReadesGroupServices dot com
Description:
Sorry but I didn't know how to best word the summary.
I have a custom method with an if statement inside. If the parameter
passed through matches "Test", a string is echo'ed. However if I pass
"0" through as the parameter, PHP thinks this is "Test" and echoes the
string.
Passing a blank parameter through, i.e. "", does not have the same
effect as "0".
Inserting "if (empty($str))" before the if statement in the example
works as expected, catches the "0" parameter and I get the expected
result. However without this, I get the actual result.
All plugins have been disabled and Apache restarted.
Test script:
---
';
}
}
testMethod('Test');
testMethod(0);
testMethod();
testMethod(1);
testMethod('Something');
?>
Expected result:
Test String!
Actual result:
--
Test String!
Test String!
Test String!
--
Edit this bug report at http://bugs.php.net/bug.php?id=52031&edit=1
[PHP-BUG] Bug #52031 [NEW]: Passing "0" as a parameter through a custom method
From:
Operating system: CentOS 5.5
PHP version: 5.3.2
Package: Unknown/Other Function
Bug Type: Bug
Bug description:Passing "0" as a parameter through a custom method
Description:
Sorry but I didn't know how to best word the summary.
I have a custom method with an if statement inside. If the parameter passed
through matches "Test", a string is echo'ed. However if I pass "0" through
as the parameter, PHP thinks this is "Test" and echoes the string.
Passing a blank parameter through, i.e. "", does not have the same effect
as "0".
Inserting "if (empty($str))" before the if statement in the example works
as expected, catches the "0" parameter and I get the expected result.
However without this, I get the actual result.
All plugins have been disabled and Apache restarted.
Test script:
---
';
}
}
testMethod('Test');
testMethod(0);
testMethod();
testMethod(1);
testMethod('Something');
?>
Expected result:
Test String!
Actual result:
--
Test String!
Test String!
Test String!
--
Edit bug report at http://bugs.php.net/bug.php?id=52031&edit=1
--
Try a snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=52031&r=trysnapshot52
Try a snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=52031&r=trysnapshot53
Try a snapshot (trunk):
http://bugs.php.net/fix.php?id=52031&r=trysnapshottrunk
Fixed in SVN:
http://bugs.php.net/fix.php?id=52031&r=fixed
Fixed in SVN and need be documented:
http://bugs.php.net/fix.php?id=52031&r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=52031&r=alreadyfixed
Need backtrace:
http://bugs.php.net/fix.php?id=52031&r=needtrace
Need Reproduce Script:
http://bugs.php.net/fix.php?id=52031&r=needscript
Try newer version:
http://bugs.php.net/fix.php?id=52031&r=oldversion
Not developer issue:
http://bugs.php.net/fix.php?id=52031&r=support
Expected behavior:
http://bugs.php.net/fix.php?id=52031&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=52031&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=52031&r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=52031&r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=52031&r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=52031&r=dst
IIS Stability:
http://bugs.php.net/fix.php?id=52031&r=isapi
Install GNU Sed:
http://bugs.php.net/fix.php?id=52031&r=gnused
Floating point limitations:
http://bugs.php.net/fix.php?id=52031&r=float
No Zend Extensions:
http://bugs.php.net/fix.php?id=52031&r=nozend
MySQL Configuration Error:
http://bugs.php.net/fix.php?id=52031&r=mysqlcfg
