Bug #55253 [Com]: DateTime::add() and sub() result -1 hour on objects with time zone type 2
Edit report at https://bugs.php.net/bug.php?id=55253edit=1 ID: 55253 Comment by: lonnyk at gmail dot com Reported by:danielc at analysisandsolutions dot com Summary:DateTime::add() and sub() result -1 hour on objects with time zone type 2 Status: Closed Type: Bug Package:Date/time related Operating System: Ubuntu 10.04 PHP Version:5.4SVN-2011-07-20 (SVN) Assigned To:derick Block user comment: N Private report: N New Comment: Just want to put an FYI in this report: It seems as though this fix caused bug #62561 Previous Comments: [2012-07-24 23:38:28] ras...@php.net Automatic comment on behalf of derick Revision: http://git.php.net/?p=php-src.git;a=commit;h=d0a898d2a2852e697ea3d3bde6136993b75ad4f4 Log: - Fixed bug #60236 (TLA timezone dates are not converted properly from timestamp). - Fixed bug #55253 (DateTime::add() and sub() result -1 hour on objects with time zone type 2). [2012-04-18 09:47:21] larue...@php.net Automatic comment on behalf of derick Revision: http://git.php.net/?p=php-src.git;a=commit;h=d0a898d2a2852e697ea3d3bde6136993b75ad4f4 Log: - Fixed bug #60236 (TLA timezone dates are not converted properly from timestamp). - Fixed bug #55253 (DateTime::add() and sub() result -1 hour on objects with time zone type 2). [2011-12-28 01:12:48] dani...@php.net Automatic comment from SVN on behalf of danielc Revision: http://svn.php.net/viewvc/?view=revisionamp;revision=321456 Log: Resolve the last of the xfails from Bug 55253. [2011-12-27 19:43:48] dani...@php.net Automatic comment from SVN on behalf of danielc Revision: http://svn.php.net/viewvc/?view=revisionamp;revision=321447 Log: Resolve more xfails due to Bug 55253 being fixed. [2011-12-27 16:57:11] dani...@php.net Automatic comment from SVN on behalf of danielc Revision: http://svn.php.net/viewvc/?view=revisionamp;revision=321442 Log: Resolve some xfails due to Bug 55253 being fixed. (merged from 54) 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 https://bugs.php.net/bug.php?id=55253 -- Edit this bug report at https://bugs.php.net/bug.php?id=55253edit=1
Bug #62896 [Com]: DateTime-modify('+0 days') Modifies DateTime Object
Edit report at https://bugs.php.net/bug.php?id=62896edit=1
ID: 62896
Comment by: lonnyk at gmail dot com
Reported by:hoang dot nguyen at groupion dot com
Summary:DateTime-modify('+0 days') Modifies DateTime
Object
Status: Open
Type: Bug
Package:Date/time related
Operating System: Windows, Linux
PHP Version:5.4Git-2012-08-22 (snap)
Block user comment: N
Private report: N
New Comment:
This seems to be related to bug #62561
Previous Comments:
[2012-08-22 15:30:30] hoang dot nguyen at groupion dot com
Description:
Calling modify() with a delta of 0 should not change the time, regardless of
whether a time zone was defined for the DateTime object or not, and independent
from how the object was created (from a UNIX timestamp or a date/time string
with or without time zone).
Test script:
---
See long version with more details and possible regressions here:
http://pastebin.com/v8RybhVh
Below is a short excerpt for the current bug.
?php
echo FROM TIMESTAMP, NO TZ:\n;
$date = new DateTime('@'.strtotime('2012-08-22 00:00:00 CEST'));
echo $date-format('Y-m-d H:i:s T').' (offset '.$date-getOffset().)\n;
$date-modify('+0 days');
echo $date-format('Y-m-d H:i:s T').' (offset '.$date-getOffset().)\n;
?
Expected result:
FROM TIMESTAMP, NO TZ:
2012-08-21 22:00:00 GMT+ (offset 0) -- should be equal
2012-08-21 22:00:00 GMT+ (offset 0) -- to this
FROM TIMESTAMP, WITH TZ:
2012-08-22 00:00:00 CEST (offset 7200)
2012-08-22 00:00:00 CEST (offset 7200)
FROM STRING:
2012-08-22 00:00:00 CEST (offset 7200)
2012-08-22 00:00:00 CEST (offset 7200)
Actual result:
--
Output from PHP 5.4.4, 5.4.6 and snapshot r4e56105 from August 22, 2012:
FROM TIMESTAMP, NO TZ:
2012-08-21 22:00:00 GMT+ (offset 0) -- different
2012-08-21 23:00:00 GMT+ (offset 0) -- from this
FROM TIMESTAMP, WITH TZ:
2012-08-22 00:00:00 CEST (offset 7200)
2012-08-22 00:00:00 CEST (offset 7200)
FROM STRING:
2012-08-22 00:00:00 CEST (offset 7200)
2012-08-22 00:00:00 CEST (offset 7200)
In PHP 5.2.0, the bug appears when creating DateTime from a string (with time
zone), which one might test as well to guard against similar bugs:
FROM TIMESTAMP, NO TZ:
2012-08-21 22:00:00 GMT+0100 (offset 7200)
2012-08-21 22:00:00 GMT+0100 (offset 7200)
FROM TIMESTAMP, WITH TZ:
2012-08-22 00:00:00 CEST (offset 7200)
2012-08-22 00:00:00 CEST (offset 7200)
FROM STRING:
2012-08-22 00:00:00 CEST (offset 7200) -- different
2012-08-21 23:00:00 CEST (offset 7200) -- from this
--
Edit this bug report at https://bugs.php.net/bug.php?id=62896edit=1
Bug #62561 [Com]: DateTime add 'P1D' adds 25 hours
Edit report at https://bugs.php.net/bug.php?id=62561edit=1
ID: 62561
Comment by: lonnyk at gmail dot com
Reported by:zach dot bailey at pardot dot com
Summary:DateTime add 'P1D' adds 25 hours
Status: Open
Type: Bug
Package:Date/time related
Operating System: Mac OS X 10.7.4
PHP Version:5.3.14
Block user comment: N
Private report: N
New Comment:
This seems to be related to bug #62896
Previous Comments:
[2012-09-29 02:32:09] lonnyk at gmail dot com
This bug is the result of the fix for bug #55253 and bug #60236
[2012-08-17 14:00:54] adam at lundrigan dot ca
Confirmed using PHP 5.3.16 (compiled from src) on RHEL 5.8
Failing PHPT test:
https://github.com/adamlundrigan/php-src/blob/409bf5d69aa2889d910af1b8edfe159febae/ext/date/tests/bug62561.phpt
[2012-07-13 21:41:27] zach dot bailey at pardot dot com
Description:
When a DateTime is constructed with a non-UTC timezone and one day is added,
the
time also jumps forward by an hour as well.
Test script:
---
$ts = new DateTime('@1341115200', new DateTimeZone('America/New_York'));
$dayFromTs = new DateTime('@1341115200', new DateTimeZone('America/New_York'));
$dayFromTs-add(new DateInterval('P1D'));
echo 'ts: '.$ts-format('Y-m-d H:i:s').\n;
echo 'day from ts: '.$dayFromTs-format('Y-m-d H:i:s').\n;
Expected result:
ts: 2012-07-01 04:00:00
day from ts: 2012-07-02 04:00:00
Actual result:
--
ts: 2012-07-01 04:00:00
day from ts: 2012-07-02 05:00:00
--
Edit this bug report at https://bugs.php.net/bug.php?id=62561edit=1
Bug #62561 [Com]: DateTime add 'P1D' adds 25 hours
Edit report at https://bugs.php.net/bug.php?id=62561edit=1
ID: 62561
Comment by: lonnyk at gmail dot com
Reported by:zach dot bailey at pardot dot com
Summary:DateTime add 'P1D' adds 25 hours
Status: Open
Type: Bug
Package:Date/time related
Operating System: Mac OS X 10.7.4
PHP Version:5.3.14
Block user comment: N
Private report: N
New Comment:
A potential fix is available https://github.com/php/php-src/pull/210
Previous Comments:
[2012-09-30 00:50:22] lonnyk at gmail dot com
This seems to be related to bug #62896
[2012-09-29 02:32:09] lonnyk at gmail dot com
This bug is the result of the fix for bug #55253 and bug #60236
[2012-08-17 14:00:54] adam at lundrigan dot ca
Confirmed using PHP 5.3.16 (compiled from src) on RHEL 5.8
Failing PHPT test:
https://github.com/adamlundrigan/php-src/blob/409bf5d69aa2889d910af1b8edfe159febae/ext/date/tests/bug62561.phpt
[2012-07-13 21:41:27] zach dot bailey at pardot dot com
Description:
When a DateTime is constructed with a non-UTC timezone and one day is added,
the
time also jumps forward by an hour as well.
Test script:
---
$ts = new DateTime('@1341115200', new DateTimeZone('America/New_York'));
$dayFromTs = new DateTime('@1341115200', new DateTimeZone('America/New_York'));
$dayFromTs-add(new DateInterval('P1D'));
echo 'ts: '.$ts-format('Y-m-d H:i:s').\n;
echo 'day from ts: '.$dayFromTs-format('Y-m-d H:i:s').\n;
Expected result:
ts: 2012-07-01 04:00:00
day from ts: 2012-07-02 04:00:00
Actual result:
--
ts: 2012-07-01 04:00:00
day from ts: 2012-07-02 05:00:00
--
Edit this bug report at https://bugs.php.net/bug.php?id=62561edit=1
Req #54567 [Com]: DateTimeZone does not serialize
Edit report at https://bugs.php.net/bug.php?id=54567edit=1
ID: 54567
Comment by: lonnyk at gmail dot com
Reported by:levi at alliancesoftware dot com dot au
Summary:DateTimeZone does not serialize
Status: Open
Type: Feature/Change Request
Package:Date/time related
Operating System: -
PHP Version:5.3.6
Block user comment: N
Private report: N
New Comment:
Here is a potential PR for this bug: https://github.com/php/php-src/pull/208
Previous Comments:
[2011-04-19 07:30:17] levi at alliancesoftware dot com dot au
Description:
http://bugs.php.net/bug.php?id=41334 -- DateTime serialization was added in PHP
5.3, but DateTimeZone still serializes to an empty object, it's serialized
string is always:
O:12:DateTimeZone:0:{}
Test script:
---
?
$x = new DateTimeZone('Australia/Victoria');
echo $x-getName().\n;
$x = serialize($x);
$x = unserialize($x);
echo $x-getName().\n;
?
Expected result:
Australia/Victoria
Australia/Victoria
Actual result:
--
Australia/Victoria
PHP Warning: DateTimeZone::getName(): The DateTimeZone object has not been
correctly initialized by its constructor in - on line 7
Warning: DateTimeZone::getName(): The DateTimeZone object has not been
correctly initialized by its constructor in - on line 7
--
Edit this bug report at https://bugs.php.net/bug.php?id=54567edit=1
Bug #62561 [Com]: DateTime add 'P1D' adds 25 hours
Edit report at https://bugs.php.net/bug.php?id=62561edit=1
ID: 62561
Comment by: lonnyk at gmail dot com
Reported by:zach dot bailey at pardot dot com
Summary:DateTime add 'P1D' adds 25 hours
Status: Open
Type: Bug
Package:Date/time related
Operating System: Mac OS X 10.7.4
PHP Version:5.3.14
Block user comment: N
Private report: N
New Comment:
This bug is the result of the fix for bug #55253 and bug #60236
Previous Comments:
[2012-08-17 14:00:54] adam at lundrigan dot ca
Confirmed using PHP 5.3.16 (compiled from src) on RHEL 5.8
Failing PHPT test:
https://github.com/adamlundrigan/php-src/blob/409bf5d69aa2889d910af1b8edfe159febae/ext/date/tests/bug62561.phpt
[2012-07-13 21:41:27] zach dot bailey at pardot dot com
Description:
When a DateTime is constructed with a non-UTC timezone and one day is added,
the
time also jumps forward by an hour as well.
Test script:
---
$ts = new DateTime('@1341115200', new DateTimeZone('America/New_York'));
$dayFromTs = new DateTime('@1341115200', new DateTimeZone('America/New_York'));
$dayFromTs-add(new DateInterval('P1D'));
echo 'ts: '.$ts-format('Y-m-d H:i:s').\n;
echo 'day from ts: '.$dayFromTs-format('Y-m-d H:i:s').\n;
Expected result:
ts: 2012-07-01 04:00:00
day from ts: 2012-07-02 04:00:00
Actual result:
--
ts: 2012-07-01 04:00:00
day from ts: 2012-07-02 05:00:00
--
Edit this bug report at https://bugs.php.net/bug.php?id=62561edit=1
Bug #62940 [Com]: getopt does not support long options without short options
Edit report at https://bugs.php.net/bug.php?id=62940edit=1
ID: 62940
Comment by: lonnyk at gmail dot com
Reported by:b8kich at gmail dot com
Summary:getopt does not support long options without short
options
Status: Open
Type: Bug
Package:PHP options/info functions
Operating System: Linux (Centos 6.3)
PHP Version:5.4.6
Block user comment: N
Private report: N
New Comment:
I am not having any problems with this:
$ php -v
PHP 5.4.6RC1 (cli) (built: Aug 30 2012 20:24:11) (DEBUG)
$ php ../tests/issue-62940.php --required value --optional=optional value --
option
array(3) {
[required]=
string(5) value
[optional]=
string(14) optional value
[option]=
bool(false)
}
Can you please provide the _exact_ command you are using for calling the script?
Previous Comments:
[2012-08-26 18:37:45] b8kich at gmail dot com
Description:
When only long options are required in getopt (without any short options), they
are not captured.
Found this in 5.3.15 (CentOS 5.8) and confirmed in 5.4.6 (CentOS 6.3)
Test script:
---
script.php:
?php
$longopts = array(
required:, // Required value
optional::,// Optional value
option,// No value
opt, // No value
);
$options = getopt(, $longopts);
var_dump($options);
?
Expected result:
The long options should be captured even if there are not short ones:
array(3) {
[required]=
string(5) value
[optional]=
string(14) optional value
[option]=
bool(false)
}
Actual result:
--
$ php script.php -f value for f --required value --optional=optional value
--option
array(0) {
}
Throwing in some short options does not help either:
$ php script.php -f value for f -v -a --required value --optional=optional
value --option
array(0) {
}
--
Edit this bug report at https://bugs.php.net/bug.php?id=62940edit=1
Req #42691 [Com]: array_reduce: initial parameter should allow non-numeric values
Edit report at https://bugs.php.net/bug.php?id=42691edit=1
ID: 42691
Comment by: lonnyk at gmail dot com
Reported by:tjerk dot meesters at muvee dot com
Summary:array_reduce: initial parameter should allow
non-numeric values
Status: Open
Type: Feature/Change Request
Package:Arrays related
Operating System: Linux 2.6
PHP Version:5.2.4
Block user comment: N
Private report: N
New Comment:
This has been added in 5.3. I just tested it with PHP 5.4.5-dev and it works.
Previous Comments:
[2007-09-18 02:27:59] tjerk dot meesters at muvee dot com
Description:
array_reduce() accepts an initial value to be passed as the first argument in
the callback function instead of NULL.
However, this initial value - if passed - is converted to an int. This is
probably because the more common use of this idiom is for mathematical
reduction.
It would be helpful to allow other types to be passed such as strings or
objects.
Note: this ticket is a duplicate for #42566, but the reporter never bothered to
follow up.
Reproduce code:
---
?php
echo array_reduce(
array(' ','world'),
create_function(
'$total,$new',
'return $total.$new;'
),
'hello'
);
?
Expected result:
hello world
Actual result:
--
0 world
--
Edit this bug report at https://bugs.php.net/bug.php?id=42691edit=1
Req #55218 [Com]: missing a way to know if namespace was declared on current node
Edit report at https://bugs.php.net/bug.php?id=55218edit=1
ID: 55218
Comment by: lonnyk at gmail dot com
Reported by:jerikojerk at gmail dot com
Summary:missing a way to know if namespace was declared on
current node
Status: Open
Type: Feature/Change Request
Package:SimpleXML related
Operating System: ubuntu
PHP Version:5.3SVN-2011-07-16 (snap)
Block user comment: N
Private report: N
New Comment:
Updated the patch on GitHub https://github.com/php/php-src/pull/112
Previous Comments:
[2012-06-19 22:18:55] renaud dot savalle at gmail dot com
I am working with complex XML files with namespaces declarations spread across
different elements. In particular I need to be able to test if a particular
namespace is declared in a certain node, and as pointed out by the requester,
there is currently no way to do that with SimpleXMLElement. Therefore I would
find Lonny's patch useful for my work and wish it could be included into PHP.
[2011-07-22 23:20:24] lonnyk at gmail dot com
I modified the definition of getDocNamespaces to be:
public array SimpleXMLElement::getDocNamespaces ([ bool $recursive = false [,
bool $from_root = true ] ] )
If the second param is set to true then the method performs exactly as it does
now. If it is set to false it performs as requested.
I choose to modify the method instead of creating a new one because I feel this
is more of a configuration option for the same functionality. If anyone has a
different opinion please let me know.
[2011-07-16 18:45:43] jerikojerk at gmail dot com
Description:
---
From manual page:
http://www.php.net/simplexmlelement.getdocnamespaces%23Voir%20aussi
---
There is no way to know when you're on a SimpleXMLElement, if there were a new
namespace declared on current node.
It's due to getDocNamespaces or getNamespaces returning xmlns status for all
the document or document root only.
It's conform to what is described in the documentation but as user we may
expect a different behavior.
Test script:
---
?php
//phpinfo();
$x = new SimpleXMLElement(
'?xml version=1.0 standalone=yes?
people xmlns:p=http://example.org/p;
person id=1 xmlns:t=http://example.org/t;
nameJohn Doe/name
/person
person id=2Susie Q. Public/person
o
divjdslkfjsldk jskdfjsmlkjfkldjkjflskj kljfslkjf sldk/div
/o
/people');
//echo 'pre',$x-asXML(),'/pre';
echo \nbrrecursive: br\n;
//$tmp = $x-getNamespaces(true) ;
//var_dump($tmp);
$tmp = $x-getDocNamespaces(true) ;
var_dump($tmp);
echo \nbr\n;
//$tmp = $x-person[0]-getNamespaces(true) ;
//var_dump($tmp);
$tmp = $x-person[0]-getDocNamespaces(true) ;
var_dump($tmp);
echo \nbr\n;
//$tmp = $x-person[1]-getNamespaces(true) ;
//var_dump($tmp);
$tmp = $x-person[1]-getDocNamespaces(true) ;
var_dump($tmp);
*/
echo \nbrnon recursive: br\n;
//$tmp = $x-getNamespaces(false) ;
//var_dump($tmp);
$tmp = $x-getDocNamespaces(false) ;
var_dump($tmp);
echo \nbr\n;
//$tmp = $x-person[0]-getNamespaces(false) ;
//var_dump($tmp);
$tmp = $x-person[0]-getDocNamespaces(false) ;
var_dump($tmp);
echo \nbr\n;
//$tmp = $x-person[1]-getNamespaces(false) ;
//var_dump($tmp);
$tmp = $x-person[1]-getDocNamespaces(false) ;
var_dump($tmp);
Expected result:
if we were able to provide namespace declare only on current node instead of
root node, the function will provide the following result
recursive:
array(2) { [p]= string(20) http://example.org/p; [t]= string(20)
http://example.org/t; }
array(1) { [t]= string(20) http://example.org/t; }
array(0) { }
non recursive:
array(1) { [p]= string(20) http://example.org/p; }
array(1) { [t]= string(20) http://example.org/t; }
array(0) { }
Actual result:
--
recursive:
array(2) { [p]= string(20) http://example.org/p; [t]= string(20)
http://example.org/t; }
array(2) { [p]= string(20) http://example.org/p; [t]= string(20)
http://example.org/t; }
array(2) { [p]= string(20) http://example.org/p; [t]= string(20)
http://example.org/t; }
non recursive:
array(1) { [p]= string(20) http://example.org/p; }
array(1) { [p]= string(20) http://example.org/p; }
array(1) { [p]= string(20) http://example.org/p; }
--
Edit this bug report at https://bugs.php.net/bug.php?id=55218edit=1
[PHP-BUG] Bug #55546 [NEW]: Bad Test for strtolower/strtoupper
From: Operating system: OSX PHP version: 5.4SVN-2011-08-31 (SVN) Package: Strings related Bug Type: Bug Bug description:Bad Test for strtolower/strtoupper Description: On Mac OSX both of these fail: Test strtolower() function [ext/standard/tests/strings/strtolower.phpt] Test strtoupper() function [ext/standard/tests/strings/strtoupper1.phpt] In both we test ASCII characters 0-255 and we fail somewhere after 127. We should not test ASCII 127 because it is undocumented and always has a different implementation. -- Edit bug report at https://bugs.php.net/bug.php?id=55546edit=1 -- Try a snapshot (PHP 5.4): https://bugs.php.net/fix.php?id=55546r=trysnapshot54 Try a snapshot (PHP 5.3): https://bugs.php.net/fix.php?id=55546r=trysnapshot53 Try a snapshot (trunk): https://bugs.php.net/fix.php?id=55546r=trysnapshottrunk Fixed in SVN: https://bugs.php.net/fix.php?id=55546r=fixed Fixed in SVN and need be documented: https://bugs.php.net/fix.php?id=55546r=needdocs Fixed in release: https://bugs.php.net/fix.php?id=55546r=alreadyfixed Need backtrace: https://bugs.php.net/fix.php?id=55546r=needtrace Need Reproduce Script: https://bugs.php.net/fix.php?id=55546r=needscript Try newer version: https://bugs.php.net/fix.php?id=55546r=oldversion Not developer issue: https://bugs.php.net/fix.php?id=55546r=support Expected behavior: https://bugs.php.net/fix.php?id=55546r=notwrong Not enough info: https://bugs.php.net/fix.php?id=55546r=notenoughinfo Submitted twice: https://bugs.php.net/fix.php?id=55546r=submittedtwice register_globals: https://bugs.php.net/fix.php?id=55546r=globals PHP 4 support discontinued: https://bugs.php.net/fix.php?id=55546r=php4 Daylight Savings:https://bugs.php.net/fix.php?id=55546r=dst IIS Stability: https://bugs.php.net/fix.php?id=55546r=isapi Install GNU Sed: https://bugs.php.net/fix.php?id=55546r=gnused Floating point limitations: https://bugs.php.net/fix.php?id=55546r=float No Zend Extensions: https://bugs.php.net/fix.php?id=55546r=nozend MySQL Configuration Error: https://bugs.php.net/fix.php?id=55546r=mysqlcfg
Bug #55200 [Com]: str_getcsv parses lines incorrectly
Edit report at https://bugs.php.net/bug.php?id=55200edit=1
ID: 55200
Comment by: lonnyk at gmail dot com
Reported by:dmitry dot dulepov at gmail dot com
Summary:str_getcsv parses lines incorrectly
Status: Open
Type: Bug
Package:Unknown/Other Function
PHP Version:5.3.6
Block user comment: N
Private report: N
New Comment:
str_getcsv is a conversion tool and not an input validator. Any invalid input
is
surely not going to work correctly and I do not think it is good practice to
account for bad input b/c it would cause extra processing time when it is not
needed.
If the input were:
var_dump(str_getcsv('123 a , 456 ', ',', ''))
what would you expect str_getcsv to do?
Previous Comments:
[2011-07-13 09:10:16] dmitry dot dulepov at gmail dot com
Description:
Putting a space around the separator *and* using quotes around fields adds
spaces to the field. The following line:
123 , 456
should produce:
123 and 456
but it makes:
123 and 456.
In the RFC4180 the specification suggests that if the field contains quotes,
only the text inside quotes is the content of the field. Here is the formal
gramma:
record = field *(COMMA field)
field = (escaped / non-escaped)
escaped = DQUOTE *(TEXTDATA / COMMA / CR / LF / 2DQUOTE) DQUOTE
non-escaped = *TEXTDATA
Thus spaces should appear in field only if the field is not quoted.
Test script:
---
print_r(str_getcsv('123 , 456 ', ',', ''))
Expected result:
array(
0 = 123,
1 = 456,
)
Actual result:
--
array(
0 = 123 ,
1 = 456 ,
)
--
Edit this bug report at https://bugs.php.net/bug.php?id=55200edit=1
Req #55218 [Com]: missing a way to know if namespace was declared on current node
Edit report at https://bugs.php.net/bug.php?id=55218edit=1
ID: 55218
Comment by: lonnyk at gmail dot com
Reported by:jerikojerk at gmail dot com
Summary:missing a way to know if namespace was declared on
current node
Status: Open
Type: Feature/Change Request
Package:SimpleXML related
Operating System: ubuntu
PHP Version:5.3SVN-2011-07-16 (snap)
Block user comment: N
Private report: N
New Comment:
I modified the definition of getDocNamespaces to be:
public array SimpleXMLElement::getDocNamespaces ([ bool $recursive = false [,
bool $from_root = true ] ] )
If the second param is set to true then the method performs exactly as it does
now. If it is set to false it performs as requested.
I choose to modify the method instead of creating a new one because I feel this
is more of a configuration option for the same functionality. If anyone has a
different opinion please let me know.
Previous Comments:
[2011-07-16 18:45:43] jerikojerk at gmail dot com
Description:
---
From manual page:
http://www.php.net/simplexmlelement.getdocnamespaces%23Voir%20aussi
---
There is no way to know when you're on a SimpleXMLElement, if there were a new
namespace declared on current node.
It's due to getDocNamespaces or getNamespaces returning xmlns status for all
the document or document root only.
It's conform to what is described in the documentation but as user we may
expect a different behavior.
Test script:
---
?php
//phpinfo();
$x = new SimpleXMLElement(
'?xml version=1.0 standalone=yes?
people xmlns:p=http://example.org/p;
person id=1 xmlns:t=http://example.org/t;
nameJohn Doe/name
/person
person id=2Susie Q. Public/person
o
divjdslkfjsldk jskdfjsmlkjfkldjkjflskj kljfslkjf sldk/div
/o
/people');
//echo 'pre',$x-asXML(),'/pre';
echo \nbrrecursive: br\n;
//$tmp = $x-getNamespaces(true) ;
//var_dump($tmp);
$tmp = $x-getDocNamespaces(true) ;
var_dump($tmp);
echo \nbr\n;
//$tmp = $x-person[0]-getNamespaces(true) ;
//var_dump($tmp);
$tmp = $x-person[0]-getDocNamespaces(true) ;
var_dump($tmp);
echo \nbr\n;
//$tmp = $x-person[1]-getNamespaces(true) ;
//var_dump($tmp);
$tmp = $x-person[1]-getDocNamespaces(true) ;
var_dump($tmp);
*/
echo \nbrnon recursive: br\n;
//$tmp = $x-getNamespaces(false) ;
//var_dump($tmp);
$tmp = $x-getDocNamespaces(false) ;
var_dump($tmp);
echo \nbr\n;
//$tmp = $x-person[0]-getNamespaces(false) ;
//var_dump($tmp);
$tmp = $x-person[0]-getDocNamespaces(false) ;
var_dump($tmp);
echo \nbr\n;
//$tmp = $x-person[1]-getNamespaces(false) ;
//var_dump($tmp);
$tmp = $x-person[1]-getDocNamespaces(false) ;
var_dump($tmp);
Expected result:
if we were able to provide namespace declare only on current node instead of
root node, the function will provide the following result
recursive:
array(2) { [p]= string(20) http://example.org/p; [t]= string(20)
http://example.org/t; }
array(1) { [t]= string(20) http://example.org/t; }
array(0) { }
non recursive:
array(1) { [p]= string(20) http://example.org/p; }
array(1) { [t]= string(20) http://example.org/t; }
array(0) { }
Actual result:
--
recursive:
array(2) { [p]= string(20) http://example.org/p; [t]= string(20)
http://example.org/t; }
array(2) { [p]= string(20) http://example.org/p; [t]= string(20)
http://example.org/t; }
array(2) { [p]= string(20) http://example.org/p; [t]= string(20)
http://example.org/t; }
non recursive:
array(1) { [p]= string(20) http://example.org/p; }
array(1) { [p]= string(20) http://example.org/p; }
array(1) { [p]= string(20) http://example.org/p; }
--
Edit this bug report at https://bugs.php.net/bug.php?id=55218edit=1
Req #55241 [Com]: return proper FALSE value when mb_substr parameters are not computable
Edit report at https://bugs.php.net/bug.php?id=55241edit=1 ID: 55241 Comment by: lonnyk at gmail dot com Reported by:netmosfera at gmail dot com Summary:return proper FALSE value when mb_substr parameters are not computable Status: Open Type: Feature/Change Request Package:mbstring related Operating System: any PHP Version:5.4.0alpha2 Block user comment: N Private report: N New Comment: This was taken care of in https://bugs.php.net/bug.php?id=28899 If you turn on mbstring.func_overload mb_substr will return false. Otherwise it returns Previous Comments: [2011-07-19 11:59:10] netmosfera at gmail dot com Description: hi, it is possible to make mb_substr work exactly like substr? substr(,0,10) // returns false mb_substr(,0,10) // returns substr(abc,7,1) // returns false mb_substr(abc,7,1) // returns thank you -- Edit this bug report at https://bugs.php.net/bug.php?id=55241edit=1
Req #55241 [Com]: return proper FALSE value when mb_substr parameters are not computable
Edit report at https://bugs.php.net/bug.php?id=55241edit=1 ID: 55241 Comment by: lonnyk at gmail dot com Reported by:netmosfera at gmail dot com Summary:return proper FALSE value when mb_substr parameters are not computable Status: Open Type: Feature/Change Request Package:mbstring related Operating System: any PHP Version:5.4.0alpha2 Block user comment: N Private report: N New Comment: Bug #28899 was committed in Rev.#203546 Previous Comments: [2011-07-20 05:11:35] lonnyk at gmail dot com This was taken care of in https://bugs.php.net/bug.php?id=28899 If you turn on mbstring.func_overload mb_substr will return false. Otherwise it returns [2011-07-19 11:59:10] netmosfera at gmail dot com Description: hi, it is possible to make mb_substr work exactly like substr? substr(,0,10) // returns false mb_substr(,0,10) // returns substr(abc,7,1) // returns false mb_substr(abc,7,1) // returns thank you -- Edit this bug report at https://bugs.php.net/bug.php?id=55241edit=1
Bug #55146 [Com]: iconv_mime_decode_headers() skips some headers
Edit report at https://bugs.php.net/bug.php?id=55146edit=1 ID: 55146 Comment by: lonnyk at gmail dot com Reported by:dmitry at spamexperts dot com Summary:iconv_mime_decode_headers() skips some headers Status: Open Type: Bug Package:ICONV related Operating System: Debian Squeeze PHP Version:Irrelevant Block user comment: N Private report: N New Comment: I am trying to test/fix this, but I do not know what encoding you are trying to decode this to. Can you please let us know what encoding you are trying to decode the headers to? Thank you! Previous Comments: [2011-07-06 08:49:14] dmitry at spamexperts dot com Description: If ICONV_MIME_DECODE_CONTINUE_ON_ERROR mode is switched on the mime_decode_headers() function parses well-formed headers wrongly. Using of ICONV_MIME_DECODE_STRICT mode solve the problem. Test script: --- ?php $headers = HEADERS X-Header-One: H4sIA+NgFlsCAAA= X-Header-Two: XtLePq6GTMn8G68F0 HEADERS; echo 'Wrong decoding:br /pre'; var_dump(iconv_mime_decode_headers($headers, ICONV_MIME_DECODE_CONTINUE_ON_ERROR)); echo '/pre'; echo 'Correct decoding:br /pre'; var_dump(iconv_mime_decode_headers($headers, ICONV_MIME_DECODE_STRICT)); echo '/pre'; Expected result: Expected result is shown in the test script under Correct decoding. Actual result: -- One header is missing from the result -- Edit this bug report at https://bugs.php.net/bug.php?id=55146edit=1
Bug #55159 [Com]: fopen encodes ampersand '' as 'amp;'
Edit report at https://bugs.php.net/bug.php?id=55159edit=1
ID: 55159
Comment by: lonnyk at gmail dot com
Reported by:knappster_1 at hotmail dot com
Summary:fopen encodes ampersand '' as 'amp;'
Status: Open
Type: Bug
Package:Unknown/Other Function
Operating System: Unix
PHP Version:5.2.17
Block user comment: N
Private report: N
New Comment:
I tested this on the 5.4 alpha and did not have this problem.
Here is my test script:
--
?php
error_reporting(E_ALL);
$fh = fopen(http://finance.yahoo.com/d/quotes.csv?
s=ABTf=sl1d1t1c1ohgvpnbaejkro=t, r);
while( !feof( $fh ) ){
echo fgets( $fh ) . \n;
}
Result:
-
ABT,53.54,7/7/2011,4:01pm,+0.26,53.49,53.60,53.24,4932482,53.28,Abbott
Laboratori,N/A,N/A,2.87,44.59,54.24,18.56
Previous Comments:
[2011-07-07 16:32:41] knappster_1 at hotmail dot com
Description:
---
From manual page: http://www.php.net/function.fopen%23Parameters
---
The function used to return a csv file with a stock quote with PHP 5.2.9.
However, now with 5.2.17 the function will replace '' with 'amp;' and it
returns a csv file with just the text: Missing Format Variable.
It is easy to verify by using a malformed URL with '' in it and on the
resulting html, view source and the error message will show 'amp;' where ''
should be. I have been unable to locate a workaround.
Test script:
---
fopen(http://finance.yahoo.com/d/quotes.csv?s=ABTf=sl1d1t1c1ohgvpnbaejkro=t;,
r);
--
Edit this bug report at https://bugs.php.net/bug.php?id=55159edit=1
Bug #55015 [Com]: strToTime calculates wrong date
Edit report at https://bugs.php.net/bug.php?id=55015edit=1
ID: 55015
Comment by: lonnyk at gmail dot com
Reported by:cp at ltur dot de
Summary:strToTime calculates wrong date
Status: Open
Type: Bug
Package:Date/time related
Operating System: Linux
PHP Version:5.3.6
Block user comment: N
Private report: N
New Comment:
The problem is that the relative weekday was calculated before the relative
month/year. I attached a batch and a test to change the order of the
calculation.
Previous Comments:
[2011-07-01 04:52:27] lonnyk at gmail dot com
I also found that if you are using this code and the next Monday is in the next
month then the month will advance two months. I set the date to 20110630 and
ran
the exact same test script:
lonny@lonnydev:~/php/php-src-5.3$ sudo date -s 30 JUN 2011 10:00:00
Thu Jun 30 10:00:00 EDT 2011
lonny@lonnydev:~/php/php-src-5.3$ php ~/test.php
20110804 4
[2011-06-09 14:13:00] cp at ltur dot de
Description:
Hi,
strToTime calculates a Wednesday when i asked for a Monday.
php 5.3.6
Configure Command = './configure' '--disable-cgi' '--with-libedit'
PHP API = 20090626
PHP Extension = 20090626
Zend Extension = 220090626
Zend Extension Build = API220090626,NTS
PHP Extension Build = API20090626,NTS
Test script:
---
// today Y-m-d 2011-06-09
date_default_timezone_set('Europe/Berlin');
echo date('Ymd N', strToTime('next month next Monday'));
Expected result:
20110711 1
Actual result:
--
20110713 3
--
Edit this bug report at https://bugs.php.net/bug.php?id=55015edit=1
Bug #55015 [Com]: strToTime calculates wrong date
Edit report at https://bugs.php.net/bug.php?id=55015edit=1
ID: 55015
Comment by: lonnyk at gmail dot com
Reported by:cp at ltur dot de
Summary:strToTime calculates wrong date
Status: Wont fix
Type: Bug
Package:Date/time related
Operating System: Linux
PHP Version:5.3.6
Block user comment: N
Private report: N
New Comment:
Hi,
I do not know if it matters, but this bug was created when the order was
changed
in rev #213026
Previous Comments:
[2011-07-06 05:47:18] cp at ltur dot de
Hi Derick,
We can't just randomly change the order because other people may rely on it.
I understand this, but it is still a bug. It should be mentioned in the
strToTime() documentation along with the workaround you posted, so people use
the function with care.
kind regards
.cp
[2011-07-06 05:01:13] der...@php.net
We can't just randomly change the order because other people may rely on it.
What you want to do is really this:
$date = date_create(2011-06-09 00:00:00)-modify(next month)-modify(next
monday);
[2011-07-06 03:41:37] cp at ltur dot de
Hi,
i applied the patch from lonny and it works for me :-)
php date_default_timezone_set('Europe/Berlin');
php echo date('Ymd N', strToTime('next month next Monday',
mktime(0,0,0,6,9,2011)));
// prints
20110711 1
Will somebody commit his patch?
kind regards
.cp
[2011-07-06 02:10:07] lonnyk at gmail dot com
The problem is that the relative weekday was calculated before the relative
month/year. I attached a batch and a test to change the order of the
calculation.
[2011-07-01 04:52:27] lonnyk at gmail dot com
I also found that if you are using this code and the next Monday is in the next
month then the month will advance two months. I set the date to 20110630 and
ran
the exact same test script:
lonny@lonnydev:~/php/php-src-5.3$ sudo date -s 30 JUN 2011 10:00:00
Thu Jun 30 10:00:00 EDT 2011
lonny@lonnydev:~/php/php-src-5.3$ php ~/test.php
20110804 4
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
https://bugs.php.net/bug.php?id=55015
--
Edit this bug report at https://bugs.php.net/bug.php?id=55015edit=1
Bug #55015 [Com]: strToTime calculates wrong date
Edit report at https://bugs.php.net/bug.php?id=55015edit=1
ID: 55015
Comment by: lonnyk at gmail dot com
Reported by:cp at ltur dot de
Summary:strToTime calculates wrong date
Status: Open
Type: Bug
Package:Date/time related
Operating System: Linux
PHP Version:5.3.6
Block user comment: N
Private report: N
New Comment:
I also found that if you are using this code and the next Monday is in the next
month then the month will advance two months. I set the date to 20110630 and
ran
the exact same test script:
lonny@lonnydev:~/php/php-src-5.3$ sudo date -s 30 JUN 2011 10:00:00
Thu Jun 30 10:00:00 EDT 2011
lonny@lonnydev:~/php/php-src-5.3$ php ~/test.php
20110804 4
Previous Comments:
[2011-06-09 14:13:00] cp at ltur dot de
Description:
Hi,
strToTime calculates a Wednesday when i asked for a Monday.
php 5.3.6
Configure Command = './configure' '--disable-cgi' '--with-libedit'
PHP API = 20090626
PHP Extension = 20090626
Zend Extension = 220090626
Zend Extension Build = API220090626,NTS
PHP Extension Build = API20090626,NTS
Test script:
---
// today Y-m-d 2011-06-09
date_default_timezone_set('Europe/Berlin');
echo date('Ymd N', strToTime('next month next Monday'));
Expected result:
20110711 1
Actual result:
--
20110713 3
--
Edit this bug report at https://bugs.php.net/bug.php?id=55015edit=1
Bug #47643 [Com]: array_diff() takes over 3000 times longer than php 5.2.4
Edit report at http://bugs.php.net/bug.php?id=47643edit=1
ID: 47643
Comment by: lonnyk at gmail dot com
Reported by:viper7 at viper-7 dot com
Summary:array_diff() takes over 3000 times longer than php
5.2.4
Status: Assigned
Type: Bug
Package:Performance problem
Operating System: *
PHP Version:5.*, 6CVS (2009-04-13)
Assigned To:felipe
Block user comment: N
New Comment:
I feel as though the actual bug here is the fix that caused this issue.
If you
revert the fix and typecast the variables passed into the custom compare
function
as (string) then this works fine. This is in line with other non-user
defined
comparison functions, they compare as === and not ==
Previous Comments:
[2010-04-16 22:20:37] sylvain at jamendo dot com
I would also appreciate a patch, this issue made our servers crash after
a php 5.3
upgrade :-/
thanks!
[2010-02-17 20:53:53] maarten at talkin dot nl
Why dont you only reset ptr if (behavior DIFF_ASSOC) ?
[2010-01-17 12:09:15] emiel dot bruijntjes at copernica dot com
This bug is now open for 10 months. Are you still working on this?
[2009-07-09 20:38:20] j...@php.net
As Dmitry's noted, this is side-effect your fix caused.
[2009-07-01 15:32:01] dmi...@php.net
The problems occurs because of bad patch for bug #42838.
The diff algorithm sorts arrays using qsort and then assumes that they
are sorted correctly. But in case of user compaison function it can't be
guaranteed. Thus in ext/standard/tests/array/bug42838.phpt
key_compare_func() can't sort array correctly because expressions (0
'a') and (0 'a') both false ('a' is interpreted as a number 0).
It should be fixed in some way
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=47643
--
Edit this bug report at http://bugs.php.net/bug.php?id=47643edit=1
