[PHP-BUG] Bug #54481 [NEW]: date_default_timezone_get() returns incorrect timezone
From: Operating system: Linux/Ubuntu PHP version: Irrelevant Package: Date/time related Bug Type: Bug Bug description:date_default_timezone_get() returns incorrect timezone Description: We noticed a discrepancy between PHP and the server timezones, and found that one four different servers (with two different versions of PHP - 5.2.4 and 5.3.2) the server was set to Australia/Adelaide (ACST), but this date_default_timezone_get() was returning Asia/Jayapura (EIT). There is no value in date.timezone (it is commented out) in the CLI and Apache PHP configuration files - so according to the documentation, PHP should be getting the timezone from the server configuration. Why is it getting this random Asia/Jayapura value? --- >From manual page: http://www.php.net/function.date-default-timezone-get#Description --- Test script: --- echo date_default_timezone_get(); Expected result: The correct timezone - not Asia/Jayapura when the server is set to Australia/Adelaide Actual result: -- Asia/Jayapura -- Edit bug report at http://bugs.php.net/bug.php?id=54481&edit=1 -- Try a snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=54481&r=trysnapshot52 Try a snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=54481&r=trysnapshot53 Try a snapshot (trunk): http://bugs.php.net/fix.php?id=54481&r=trysnapshottrunk Fixed in SVN: http://bugs.php.net/fix.php?id=54481&r=fixed Fixed in SVN and need be documented: http://bugs.php.net/fix.php?id=54481&r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=54481&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=54481&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=54481&r=needscript Try newer version: http://bugs.php.net/fix.php?id=54481&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=54481&r=support Expected behavior: http://bugs.php.net/fix.php?id=54481&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=54481&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=54481&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=54481&r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=54481&r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=54481&r=dst IIS Stability: http://bugs.php.net/fix.php?id=54481&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=54481&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=54481&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=54481&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=54481&r=mysqlcfg
Bug #34776 [Com]: mb_convert_encoding() - wrong convertion from UTF-16 (problem with BOM)
Edit report at http://bugs.php.net/bug.php?id=34776&edit=1
ID: 34776
Comment by: me+phpbugs at ryanmccue dot info
Reported by:narzeczony at zabuchy dot net
Summary:mb_convert_encoding() - wrong convertion from UTF-16
(problem with BOM)
Status: No Feedback
Type: Bug
Package:mbstring related
Operating System: Linux, Windows
PHP Version:5.0.5
Block user comment: N
Private report: N
New Comment:
Alternatively:
Reproduce code:
---
bin2hex(mb_convert_encoding("\xfe\xff\x22\x1e", 'UTF-8', 'UTF-16'));
Expected result:
e2889e
Actual result:
--
efbbbfe2889e
Previous Comments:
[2011-04-06 15:20:14] me+phpbugs at ryanmccue dot info
We're also able to reproduce this, with a much smaller test case:
Reproduce code:
---
mb_convert_encoding("\xfe\xff\x22\x1e", 'UTF-8', 'UTF-16');
Expected result:
\xe2\x88\x9e
Actual result:
--
\xef\xbb\xbf\xe2\x88\x9e
[2008-02-18 17:20:00] jdephix at polenord dot com
I forgot to add that I did manage to deal with the UTF-16BE file by
reversing everything.
$s = file_get_contents($fileUTF16BE);
$s = mb_convert_encoding($s, 'UTF-8', "UTF-16LE");
//some operations on $s
file_put_contents($anotherUTF16BEfile, mb_convert_encoding($s,
'UTF-16LE', "UTF-8"));
I need to specify "UTF-16LE" in order to be sure I work with "UTF-16BE".
[2008-02-18 17:16:32] jdephix at polenord dot com
UTF-16LE and UTF-16BE seem mixed up when using mb_convert_encoding.
I want to read the content of a file in UTF-16BE (starts with \xFE\xFF)
and convert it into UTF-8:
$s = file_get_contents($fileUTF16BE);
$s = mb_convert_encoding($s, 'UTF-8', "UTF-16BE");
//some operations on $s
file_put_contents($anotherUTF16BEfile, mb_convert_encoding($s,
'UTF-16BE', "UTF-8"));
The second file is in Little Endian (starts with \xFF\FE)!!!
I have to specify LE if I want BE.
file_put_contents($anotherUTF16BEfile, mb_convert_encoding($s,
'UTF-16LE', "UTF-8"));
How come it's reversed?
[2006-06-23 16:11:32] markl at lindenlab dot com
There are two problems when mb_convert_encoding is
converting from UTF-16:
1) It is including the (transcoded) BOM in the result,
rather than stripping it
2) If the source UTF-16 string was little endian, then the
second character of the conversion will be wrong; it is
converted as if the character code had 0xFF00 or'd into it.
Problem 1 occurs with any UTF-16 variant (though it is
arguably correct behavior for UTF-16LE and UTF-16BE).
Problem 2 only occurs when converting from UTF-16.
This PHP program demonstrates this all clearly:
function dump($s)
{
for ($i = 0; $i < strlen($s); ++$i) {
echo substr(dechex(256+ord(substr($s, $i, 1))), 1,
2), ' ';
}
var_dump($s);
}
$utf16le = "\xFF\xFE\x41\x00\x42\x00\x43\x00";
$utf16be = "\xFE\xFF\x00\x41\x00\x42\x00\x43";
// these strings are both valid UTF-16, the BOM at the
start indicates
// the endianness. We don't expect the BOM to be
included in a conversion
echo "The UTF-16LE and UTF-16BE sequences:\n";
dump($utf16le);
dump($utf16be);
echo "\n";
$encodings = array("ascii", "iso-8859-1", "utf-8", "utf-16",
"utf-16le", "utf-16be");
foreach ($encodings as $enc) {
echo "Converting to $enc:\n";
dump(mb_convert_encoding($utf16le, $enc, "utf-16"));
dump(mb_convert_encoding($utf16be, $enc, "utf-16"));
echo "\n";
}
[2005-10-15 01:00:03] php-bugs at lists dot php dot net
No feedback was provided for this bug for over a week, so it is
being suspended automatically. If you are able to provide the
information that was originally requested, please do so and change
the status of the bug back to "Open".
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=34776
--
Edit this bug report at http://bugs.php.net/bug.php?id=34776&edit=1
Bug #54479 [Com]: round(1e15+0.1) returns 1e15+0.1 instead of 1e15
Edit report at http://bugs.php.net/bug.php?id=54479&edit=1
ID: 54479
Comment by: for-bugs at hnw dot jp
Reported by:for-bugs at hnw dot jp
Summary:round(1e15+0.1) returns 1e15+0.1 instead of 1e15
Status: Bogus
Type: Bug
Package:Math related
Operating System: any
PHP Version:5.3.6
Block user comment: N
Private report: N
New Comment:
My test script seems to be wrong. How about next one?
= 1e15) {
return value;
}
Previous Comments:
[2011-04-06 19:39:39] der...@php.net
Floating point values have a limited precision. Hence a value might
not have the same string representation after any processing. That also
includes writing a floating point value in your script and directly
printing it without any mathematical operations.
If you would like to know more about "floats" and what IEEE
754 is, read this:
http://www.floating-point-gui.de/
Thank you for your interest in PHP.
.
[2011-04-06 19:22:45] for-bugs at hnw dot jp
Description:
When round() is called with 1 argument which value is between 1e15 and
2^53, round() returns non-rounded value even if the value has fractional
part.
For instance, though 1e15 is exact number as IEEE 754 double precision,
round(1e15+0.1) returns 1e15+0.1. I think 1e15 is better result.
Test script:
---
http://bugs.php.net/bug.php?id=54479&edit=1
Bug #54454 [ReO]: substr_compare incorrectly reports equality in some cases
Edit report at http://bugs.php.net/bug.php?id=54454&edit=1
ID: 54454
User updated by:zweibieren at yahoo dot com
Reported by:zweibieren at yahoo dot com
Summary:substr_compare incorrectly reports equality in some
cases
Status: Re-Opened
Type: Bug
Package:Strings related
Operating System: linux
PHP Version:Irrelevant
Assigned To:pierrick
Block user comment: N
Private report: N
New Comment:
Parkinson would be glad to claim as one of his laws:
The smaller the software change the bigger the discussion. !-)
Previous Comments:
[2011-04-06 20:58:45] s...@php.net
I was initially concerned that the security implications of the patch
were
reviewed. Scott did this but has a concern about BC.
[2011-04-06 10:16:44] paj...@php.net
Chris and Scott are seeing issues with this change. Reopening.
[2011-04-03 09:23:04] pierr...@php.net
This bug has been fixed in SVN.
Snapshots of the sources are packaged every three hours; this change
will be in the next snapshot. You can grab the snapshot at
http://snaps.php.net/.
Thank you for the report, and for helping us make PHP better.
[2011-04-03 09:18:30] pierr...@php.net
Automatic comment from SVN on behalf of pierrick
Revision: http://svn.php.net/viewvc/?view=revision&revision=309910
Log: Fixed bug #54454 (substr_compare incorrectly reports equality in
some cases)
[2011-04-02 23:52:11] zweibieren at yahoo dot com
Description:
---
>From manual page:
http://www.php.net/function.substr-compare#Description
int substr_compare ( string $main_str , string $str , int $offset , int
$length ... )
substr_compare() compares main_str from position offset with str up to
length characters.
Return Values
Returns < 0 if main_str from position offset is less than str, > 0 if it
is greater than str, and 0 if they are equal. ...
---
HOWEVER, if main_str is shorter than str, substr_compare checks only up
to the length of main_str. This is NOT how I read the description. I
believe the comparison should extend to length characters and render a
non-zero value if the two strings differ at any character in the first
length characters.
WORKAROUND: Use strncmp.
{Note that substr_compare advertises itself as "binary safe." Since it
is stopping at '\0', it fails to actually BE binary safe.}
Test script:
---
substr_compare("/", "/asd", 0, 4) => '
. substr_compare("/", "/asd", 0, 4)
. ' (SHOULD BE -3)'
. ' substr_compare("/asd", "/", 0, 4) => '
. substr_compare("/asd", "/", 0, 4)
. ' strncmp("/", "/asd", 4) => '
. strncmp("/", "/asd", 4)
. ' strncmp("/asd", "/", 4) => '
. strncmp("/asd", "/", 4); ?>
Expected result:
four comparisons of "/" and "/asd":
substr_compare("/", "/asd", 0, 4) => -3
substr_compare("/asd", "/", 0, 4) => 3
strncmp("/", "/asd", 4) => -3
strncmp("/asd", "/", 4) => 3
Actual result:
--
four comparisons of "/" and "/asd":
substr_compare("/", "/asd", 0, 4) => 0 (SHOULD BE -3)
substr_compare("/asd", "/", 0, 4) => 3
strncmp("/", "/asd", 4) => -3
strncmp("/asd", "/", 4) => 3
As the script says, the first reported value should be -3.
--
Edit this bug report at http://bugs.php.net/bug.php?id=54454&edit=1
Bug #54454 [ReO]: substr_compare incorrectly reports equality in some cases
Edit report at http://bugs.php.net/bug.php?id=54454&edit=1
ID: 54454
Updated by: s...@php.net
Reported by:zweibieren at yahoo dot com
Summary:substr_compare incorrectly reports equality in some
cases
Status: Re-Opened
Type: Bug
Package:Strings related
Operating System: linux
PHP Version:Irrelevant
Assigned To:pierrick
Block user comment: N
Private report: N
New Comment:
I was initially concerned that the security implications of the patch
were
reviewed. Scott did this but has a concern about BC.
Previous Comments:
[2011-04-06 10:16:44] paj...@php.net
Chris and Scott are seeing issues with this change. Reopening.
[2011-04-03 09:23:04] pierr...@php.net
This bug has been fixed in SVN.
Snapshots of the sources are packaged every three hours; this change
will be in the next snapshot. You can grab the snapshot at
http://snaps.php.net/.
Thank you for the report, and for helping us make PHP better.
[2011-04-03 09:18:30] pierr...@php.net
Automatic comment from SVN on behalf of pierrick
Revision: http://svn.php.net/viewvc/?view=revision&revision=309910
Log: Fixed bug #54454 (substr_compare incorrectly reports equality in
some cases)
[2011-04-02 23:52:11] zweibieren at yahoo dot com
Description:
---
>From manual page:
http://www.php.net/function.substr-compare#Description
int substr_compare ( string $main_str , string $str , int $offset , int
$length ... )
substr_compare() compares main_str from position offset with str up to
length characters.
Return Values
Returns < 0 if main_str from position offset is less than str, > 0 if it
is greater than str, and 0 if they are equal. ...
---
HOWEVER, if main_str is shorter than str, substr_compare checks only up
to the length of main_str. This is NOT how I read the description. I
believe the comparison should extend to length characters and render a
non-zero value if the two strings differ at any character in the first
length characters.
WORKAROUND: Use strncmp.
{Note that substr_compare advertises itself as "binary safe." Since it
is stopping at '\0', it fails to actually BE binary safe.}
Test script:
---
substr_compare("/", "/asd", 0, 4) => '
. substr_compare("/", "/asd", 0, 4)
. ' (SHOULD BE -3)'
. ' substr_compare("/asd", "/", 0, 4) => '
. substr_compare("/asd", "/", 0, 4)
. ' strncmp("/", "/asd", 4) => '
. strncmp("/", "/asd", 4)
. ' strncmp("/asd", "/", 4) => '
. strncmp("/asd", "/", 4); ?>
Expected result:
four comparisons of "/" and "/asd":
substr_compare("/", "/asd", 0, 4) => -3
substr_compare("/asd", "/", 0, 4) => 3
strncmp("/", "/asd", 4) => -3
strncmp("/asd", "/", 4) => 3
Actual result:
--
four comparisons of "/" and "/asd":
substr_compare("/", "/asd", 0, 4) => 0 (SHOULD BE -3)
substr_compare("/asd", "/", 0, 4) => 3
strncmp("/", "/asd", 4) => -3
strncmp("/asd", "/", 4) => 3
As the script says, the first reported value should be -3.
--
Edit this bug report at http://bugs.php.net/bug.php?id=54454&edit=1
Bug #54479 [Opn->Bgs]: round(1e15+0.1) returns 1e15+0.1 instead of 1e15
Edit report at http://bugs.php.net/bug.php?id=54479&edit=1 ID: 54479 Updated by: der...@php.net Reported by:for-bugs at hnw dot jp Summary:round(1e15+0.1) returns 1e15+0.1 instead of 1e15 -Status: Open +Status: Bogus Type: Bug Package:Math related Operating System: any PHP Version:5.3.6 Block user comment: N Private report: N New Comment: Floating point values have a limited precision. Hence a value might not have the same string representation after any processing. That also includes writing a floating point value in your script and directly printing it without any mathematical operations. If you would like to know more about "floats" and what IEEE 754 is, read this: http://www.floating-point-gui.de/ Thank you for your interest in PHP. . Previous Comments: [2011-04-06 19:22:45] for-bugs at hnw dot jp Description: When round() is called with 1 argument which value is between 1e15 and 2^53, round() returns non-rounded value even if the value has fractional part. For instance, though 1e15 is exact number as IEEE 754 double precision, round(1e15+0.1) returns 1e15+0.1. I think 1e15 is better result. Test script: --- http://bugs.php.net/bug.php?id=54479&edit=1
[PHP-BUG] Bug #54479 [NEW]: round(1e15+0.1) returns 1e15+0.1 instead of 1e15
From: Operating system: any PHP version: 5.3.6 Package: Math related Bug Type: Bug Bug description:round(1e15+0.1) returns 1e15+0.1 instead of 1e15 Description: When round() is called with 1 argument which value is between 1e15 and 2^53, round() returns non-rounded value even if the value has fractional part. For instance, though 1e15 is exact number as IEEE 754 double precision, round(1e15+0.1) returns 1e15+0.1. I think 1e15 is better result. Test script: --- http://bugs.php.net/bug.php?id=54479&edit=1 -- Try a snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=54479&r=trysnapshot52 Try a snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=54479&r=trysnapshot53 Try a snapshot (trunk): http://bugs.php.net/fix.php?id=54479&r=trysnapshottrunk Fixed in SVN: http://bugs.php.net/fix.php?id=54479&r=fixed Fixed in SVN and need be documented: http://bugs.php.net/fix.php?id=54479&r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=54479&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=54479&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=54479&r=needscript Try newer version: http://bugs.php.net/fix.php?id=54479&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=54479&r=support Expected behavior: http://bugs.php.net/fix.php?id=54479&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=54479&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=54479&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=54479&r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=54479&r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=54479&r=dst IIS Stability: http://bugs.php.net/fix.php?id=54479&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=54479&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=54479&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=54479&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=54479&r=mysqlcfg
Bug #54466 [Csd->Bgs]: Timezone offset for America/Caracas is wrong
Edit report at http://bugs.php.net/bug.php?id=54466&edit=1 ID: 54466 Updated by: dtajchre...@php.net Reported by:jose dot zap at gmail dot com Summary:Timezone offset for America/Caracas is wrong -Status: Closed +Status: Bogus Type: Bug Package:Date/time related PHP Version:5.3.6 Block user comment: N Private report: N New Comment: Bumping to bogus per last comment. Previous Comments: [2011-04-06 16:42:19] jose dot zap at gmail dot com Sorry for opening the ticket with so little information, and thank you very much for your reply. I was using a third party library fro listing all timezones along with their offsets and while all seemed right, this one was listed as -5.5, I tested the code you provided and in fact -4.5 is returned. I guess I'll have to fix the library instead. Again, thanks a lot for your help and sorry for wasting your time :) [2011-04-06 09:18:03] ahar...@php.net I'm rather confused by your bug: DateTimeZone::listIdentifiers() doesn't list offsets, and the code that does appears to be correct on any recent PHP version: getOffset(new DateTime()) / 3600); ?> outputs float(-4.5), which lines up with your bug. What version of PHP are you running, what does phpinfo() list the Olson Timezone Database Version as, and what do you get when you run the above code? [2011-04-04 17:38:48] jose dot zap at gmail dot com Description: When using DateTimeZone::listIdentifiers() the offset for America/Caracas is shown as GMT -5:30, when it should be GMT -4:30 This can be validated here http://www.timeanddate.com/library/abbreviations/timezones/sa/vet.html -- Edit this bug report at http://bugs.php.net/bug.php?id=54466&edit=1
Bug #54466 [Fbk->Csd]: Timezone offset for America/Caracas is wrong
Edit report at http://bugs.php.net/bug.php?id=54466&edit=1 ID: 54466 User updated by:jose dot zap at gmail dot com Reported by:jose dot zap at gmail dot com Summary:Timezone offset for America/Caracas is wrong -Status: Feedback +Status: Closed Type: Bug Package:Date/time related PHP Version:5.3.6 Block user comment: N Private report: N New Comment: Sorry for opening the ticket with so little information, and thank you very much for your reply. I was using a third party library fro listing all timezones along with their offsets and while all seemed right, this one was listed as -5.5, I tested the code you provided and in fact -4.5 is returned. I guess I'll have to fix the library instead. Again, thanks a lot for your help and sorry for wasting your time :) Previous Comments: [2011-04-06 09:18:03] ahar...@php.net I'm rather confused by your bug: DateTimeZone::listIdentifiers() doesn't list offsets, and the code that does appears to be correct on any recent PHP version: getOffset(new DateTime()) / 3600); ?> outputs float(-4.5), which lines up with your bug. What version of PHP are you running, what does phpinfo() list the Olson Timezone Database Version as, and what do you get when you run the above code? [2011-04-04 17:38:48] jose dot zap at gmail dot com Description: When using DateTimeZone::listIdentifiers() the offset for America/Caracas is shown as GMT -5:30, when it should be GMT -4:30 This can be validated here http://www.timeanddate.com/library/abbreviations/timezones/sa/vet.html -- Edit this bug report at http://bugs.php.net/bug.php?id=54466&edit=1
Bug #54422 [Opn->Fbk]: possibly a bug in file_exists() found
Edit report at http://bugs.php.net/bug.php?id=54422&edit=1 ID: 54422 Updated by: cataphr...@php.net Reported by:f dot roze dot n at hush dot ai Summary:possibly a bug in file_exists() found -Status: Open +Status: Feedback Type: Bug Package:Filesystem function related Operating System: linux PHP Version:5.3.6 Block user comment: N Private report: N New Comment: Can't reproduce this. Are you sure the filename doesn't have a backslash?... $ ls file\' 1 file' 2 $ ~/php-t/bin/php http://bugs.php.net/bug.php?id=54422&edit=1
Bug #34776 [Com]: mb_convert_encoding() - wrong convertion from UTF-16 (problem with BOM)
Edit report at http://bugs.php.net/bug.php?id=34776&edit=1
ID: 34776
Comment by: me+phpbugs at ryanmccue dot info
Reported by:narzeczony at zabuchy dot net
Summary:mb_convert_encoding() - wrong convertion from UTF-16
(problem with BOM)
Status: No Feedback
Type: Bug
Package:mbstring related
Operating System: Linux, Windows
PHP Version:5.0.5
Block user comment: N
Private report: N
New Comment:
We're also able to reproduce this, with a much smaller test case:
Reproduce code:
---
mb_convert_encoding("\xfe\xff\x22\x1e", 'UTF-8', 'UTF-16');
Expected result:
\xe2\x88\x9e
Actual result:
--
\xef\xbb\xbf\xe2\x88\x9e
Previous Comments:
[2008-02-18 17:20:00] jdephix at polenord dot com
I forgot to add that I did manage to deal with the UTF-16BE file by
reversing everything.
$s = file_get_contents($fileUTF16BE);
$s = mb_convert_encoding($s, 'UTF-8', "UTF-16LE");
//some operations on $s
file_put_contents($anotherUTF16BEfile, mb_convert_encoding($s,
'UTF-16LE', "UTF-8"));
I need to specify "UTF-16LE" in order to be sure I work with "UTF-16BE".
[2008-02-18 17:16:32] jdephix at polenord dot com
UTF-16LE and UTF-16BE seem mixed up when using mb_convert_encoding.
I want to read the content of a file in UTF-16BE (starts with \xFE\xFF)
and convert it into UTF-8:
$s = file_get_contents($fileUTF16BE);
$s = mb_convert_encoding($s, 'UTF-8', "UTF-16BE");
//some operations on $s
file_put_contents($anotherUTF16BEfile, mb_convert_encoding($s,
'UTF-16BE', "UTF-8"));
The second file is in Little Endian (starts with \xFF\FE)!!!
I have to specify LE if I want BE.
file_put_contents($anotherUTF16BEfile, mb_convert_encoding($s,
'UTF-16LE', "UTF-8"));
How come it's reversed?
[2006-06-23 16:11:32] markl at lindenlab dot com
There are two problems when mb_convert_encoding is
converting from UTF-16:
1) It is including the (transcoded) BOM in the result,
rather than stripping it
2) If the source UTF-16 string was little endian, then the
second character of the conversion will be wrong; it is
converted as if the character code had 0xFF00 or'd into it.
Problem 1 occurs with any UTF-16 variant (though it is
arguably correct behavior for UTF-16LE and UTF-16BE).
Problem 2 only occurs when converting from UTF-16.
This PHP program demonstrates this all clearly:
function dump($s)
{
for ($i = 0; $i < strlen($s); ++$i) {
echo substr(dechex(256+ord(substr($s, $i, 1))), 1,
2), ' ';
}
var_dump($s);
}
$utf16le = "\xFF\xFE\x41\x00\x42\x00\x43\x00";
$utf16be = "\xFE\xFF\x00\x41\x00\x42\x00\x43";
// these strings are both valid UTF-16, the BOM at the
start indicates
// the endianness. We don't expect the BOM to be
included in a conversion
echo "The UTF-16LE and UTF-16BE sequences:\n";
dump($utf16le);
dump($utf16be);
echo "\n";
$encodings = array("ascii", "iso-8859-1", "utf-8", "utf-16",
"utf-16le", "utf-16be");
foreach ($encodings as $enc) {
echo "Converting to $enc:\n";
dump(mb_convert_encoding($utf16le, $enc, "utf-16"));
dump(mb_convert_encoding($utf16be, $enc, "utf-16"));
echo "\n";
}
[2005-10-15 01:00:03] php-bugs at lists dot php dot net
No feedback was provided for this bug for over a week, so it is
being suspended automatically. If you are able to provide the
information that was originally requested, please do so and change
the status of the bug back to "Open".
[2005-10-07 21:58:46] sni...@php.net
Please try using this CVS snapshot:
http://snaps.php.net/php5-latest.tar.gz
For Windows:
http://snaps.php.net/win32/php5-win32-latest.zip
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=34776
--
Edit this bug report at http://bugs.php.net/bug.php?id=34776&edit=1
Bug #54478 [Opn]: The pdo_pgsql specific implementation of inTransaction doesn't work as expected
Edit report at http://bugs.php.net/bug.php?id=54478&edit=1 ID: 54478 User updated by:phofstetter at sensational dot ch Reported by:phofstetter at sensational dot ch Summary:The pdo_pgsql specific implementation of inTransaction doesn't work as expected Status: Open Type: Bug Package:PDO related Operating System: OSX, Linux, likely all PHP Version:5.3.6 Block user comment: N Private report: N New Comment: A bit of investigation revealed that the feature was removed in 300464 http://svn.php.net/viewvc?view=revision&revision=300464 I guess the unit test should be removed too, as well as the note in the manual which states "Note that currently only the PostgreSQL driver implements this method." Previous Comments: [2011-04-06 14:59:11] phofstetter at sensational dot ch Description: PHP 5.3.3 supposedly brought PDO::inTransaction() with a special implementation for PostgreSQL wich uses libpq's PQtransactionStatus instead of internal bookkeeping. According to the test attached with the revision where this was added (is_in_transaction.phpt, revision 300351), inTransaction() is supposed to return any of the PGSQL_TRANSACTION_* constants. Unfortunately that's not the case and inTransaction(), even when used in conjunction with PostgreSQL only returns boolean and doesn't use the actual transaction status of the connection but just returns true or false depending on whether PDO::beginTransaction() has been called or not. PHP's own test runner illustrates the problem, which is why I don't bother adding an additional test script - the included is_in_transaction.phpt is enough: http://gcov.php.net/viewer.php? version=PHP_5_3&func=tests&file=ext%2Fpdo_pgsql%2Ftests%2Fis_in_transaction.phpt Expected result: When running the phpt file, I expect the following output: Test PDO::PGSQL_TRANSACTION_INTRANS int(2) Test PDO::PGSQL_TRANSACTION_IDLE int(0) Test PDO::PGSQL_TRANSACTION_INERROR int(3) Test PDO::PGSQL_TRANSACTION_IDLE int(0) Actual result: -- When running the phpt file, I (and PHP's webbased test runner) is getting Test PDO::PGSQL_TRANSACTION_INTRANS int(1) Test PDO::PGSQL_TRANSACTION_IDLE int(0) Test PDO::PGSQL_TRANSACTION_INERROR int(1) Test PDO::PGSQL_TRANSACTION_IDLE int(0) -- Edit this bug report at http://bugs.php.net/bug.php?id=54478&edit=1
[PHP-BUG] Bug #54478 [NEW]: The pdo_pgsql specific implementation of inTransaction doesn't work as expected
From: Operating system: OSX, Linux, likely all PHP version: 5.3.6 Package: PDO related Bug Type: Bug Bug description:The pdo_pgsql specific implementation of inTransaction doesn't work as expected Description: PHP 5.3.3 supposedly brought PDO::inTransaction() with a special implementation for PostgreSQL wich uses libpq's PQtransactionStatus instead of internal bookkeeping. According to the test attached with the revision where this was added (is_in_transaction.phpt, revision 300351), inTransaction() is supposed to return any of the PGSQL_TRANSACTION_* constants. Unfortunately that's not the case and inTransaction(), even when used in conjunction with PostgreSQL only returns boolean and doesn't use the actual transaction status of the connection but just returns true or false depending on whether PDO::beginTransaction() has been called or not. PHP's own test runner illustrates the problem, which is why I don't bother adding an additional test script - the included is_in_transaction.phpt is enough: http://gcov.php.net/viewer.php? version=PHP_5_3&func=tests&file=ext%2Fpdo_pgsql%2Ftests%2Fis_in_transaction.phpt Expected result: When running the phpt file, I expect the following output: Test PDO::PGSQL_TRANSACTION_INTRANS int(2) Test PDO::PGSQL_TRANSACTION_IDLE int(0) Test PDO::PGSQL_TRANSACTION_INERROR int(3) Test PDO::PGSQL_TRANSACTION_IDLE int(0) Actual result: -- When running the phpt file, I (and PHP's webbased test runner) is getting Test PDO::PGSQL_TRANSACTION_INTRANS int(1) Test PDO::PGSQL_TRANSACTION_IDLE int(0) Test PDO::PGSQL_TRANSACTION_INERROR int(1) Test PDO::PGSQL_TRANSACTION_IDLE int(0) -- Edit bug report at http://bugs.php.net/bug.php?id=54478&edit=1 -- Try a snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=54478&r=trysnapshot52 Try a snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=54478&r=trysnapshot53 Try a snapshot (trunk): http://bugs.php.net/fix.php?id=54478&r=trysnapshottrunk Fixed in SVN: http://bugs.php.net/fix.php?id=54478&r=fixed Fixed in SVN and need be documented: http://bugs.php.net/fix.php?id=54478&r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=54478&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=54478&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=54478&r=needscript Try newer version: http://bugs.php.net/fix.php?id=54478&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=54478&r=support Expected behavior: http://bugs.php.net/fix.php?id=54478&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=54478&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=54478&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=54478&r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=54478&r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=54478&r=dst IIS Stability: http://bugs.php.net/fix.php?id=54478&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=54478&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=54478&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=54478&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=54478&r=mysqlcfg
Req #54459 [Opn->Csd]: Range function accuracy
Edit report at http://bugs.php.net/bug.php?id=54459&edit=1 ID: 54459 Updated by: ahar...@php.net Reported by:mail at anthonysterling dot com Summary:Range function accuracy -Status: Open +Status: Closed Type: Feature/Change Request Package:Unknown/Other Function Operating System: Mixed PHP Version:Irrelevant -Assigned To: +Assigned To:aharvey Block user comment: N Private report: N New Comment: This bug has been fixed in SVN. Snapshots of the sources are packaged every three hours; this change will be in the next snapshot. You can grab the snapshot at http://snaps.php.net/. Thank you for the report, and for helping us make PHP better. Previous Comments: [2011-04-06 12:23:08] ahar...@php.net Automatic comment from SVN on behalf of aharvey Revision: http://svn.php.net/viewvc/?view=revision&revision=309986 Log: Implement FR #54459 (Range function accuracy) by changing the way range() calculates values when used with floating point bounds/step. [2011-04-04 11:04:27] cataphr...@php.net I'm changing it to a request then. But it's clear the function currently works as documented. What you want is some sort of correction to the cumulating errors. I suppose this is possible, but do you have any algorithm to suggest here?.. [2011-04-04 09:15:50] mail at anthonysterling dot com Thanks. I understand *why* this happens, I'm just don't think this is expected nor desirable. Should this not be compensated/adjusted for before reaching user-land as the intent is pretty clear (increment in 10% steps). Thanks again. Anthony. [2011-04-04 00:13:12] cataphr...@php.net .1 is not exactly representable; the rounding error is propagated through the multiplication until it gets big enough to affect the displayed number for the desired precision. Bogus. [2011-04-03 21:29:14] mail at anthonysterling dot com Reducing the precision to a value equal to, or lower than 13 appears to address it. 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=54459 -- Edit this bug report at http://bugs.php.net/bug.php?id=54459&edit=1
Req #40510 [Sus->Csd]: Add multicast support in sockets.c
Edit report at http://bugs.php.net/bug.php?id=40510&edit=1 ID: 40510 Updated by: cataphr...@php.net Reported by:lew dot payne at gmail dot com Summary:Add multicast support in sockets.c -Status: Suspended +Status: Closed Type: Feature/Change Request Package:Sockets related Operating System: FreeBSD 6.2-REL PHP Version:5.2.1 Assigned To:cataphract Block user comment: N Private report: N New Comment: Closing. Trunk only. Previous Comments: [2011-03-14 15:54:52] cataphr...@php.net Changed package, re-assigned and more accurately classified as suspended. [2011-03-14 01:12:21] cataphr...@php.net Implemented for trunk; to be considered to 5.3 after 5.3.6 release. [2011-03-14 01:08:31] cataphr...@php.net Automatic comment from SVN on behalf of cataphract Revision: http://svn.php.net/viewvc/?view=revision&revision=309198 Log: - Added multicast support to the sockets extension (bug #40510). [2011-03-03 01:02:29] cataphr...@php.net Chris, PHP 5.2 is dead, adding this feature to it is out of question. Adding it to PHP 5.3 depends on the release master, but probably won't be possible due to the need to keep binary compatibility. [2011-03-02 11:08:52] chrisw at networkm dot co dot uk Judging by the amount of Google space taken up by people trying to do this (including myself) I am very much in favour of moving this issue forward ASAP. I also agree with the IPv6 support (to a point), but if this is to be added to PHP 5.2.x I would suggest it may not be necessary to implement at this stage. Moving forward, shouldn't we be encouraging the use of 5.3.x for new/upgrading users? In which case, I would suggest that adding full IPv6 support against 5.2 might be a waste of time - I would imagine there would be a lot of work involved in adding full IPv6 multicast/anycast support, whereas the existing supplied patch would presumably only require minor modifications to bring it into line with the current 5.2 releases. I am all in favour of fully supporting IPv6 in 5.3, but I also believe that in the interests of speed it would be useful to have this, simpler, IPv4 multicast support in 5.2. Maybe this would be considered an un-productive approach, but it's just a thought... 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=40510 -- Edit this bug report at http://bugs.php.net/bug.php?id=40510&edit=1
Bug #54454 [Csd->ReO]: substr_compare incorrectly reports equality in some cases
Edit report at http://bugs.php.net/bug.php?id=54454&edit=1
ID: 54454
Updated by: paj...@php.net
Reported by:zweibieren at yahoo dot com
Summary:substr_compare incorrectly reports equality in some
cases
-Status: Closed
+Status: Re-Opened
Type: Bug
Package:Strings related
Operating System: linux
PHP Version:Irrelevant
Assigned To:pierrick
Block user comment: N
Private report: N
New Comment:
Chris and Scott are seeing issues with this change. Reopening.
Previous Comments:
[2011-04-03 09:23:04] pierr...@php.net
This bug has been fixed in SVN.
Snapshots of the sources are packaged every three hours; this change
will be in the next snapshot. You can grab the snapshot at
http://snaps.php.net/.
Thank you for the report, and for helping us make PHP better.
[2011-04-03 09:18:30] pierr...@php.net
Automatic comment from SVN on behalf of pierrick
Revision: http://svn.php.net/viewvc/?view=revision&revision=309910
Log: Fixed bug #54454 (substr_compare incorrectly reports equality in
some cases)
[2011-04-02 23:52:11] zweibieren at yahoo dot com
Description:
---
>From manual page:
http://www.php.net/function.substr-compare#Description
int substr_compare ( string $main_str , string $str , int $offset , int
$length ... )
substr_compare() compares main_str from position offset with str up to
length characters.
Return Values
Returns < 0 if main_str from position offset is less than str, > 0 if it
is greater than str, and 0 if they are equal. ...
---
HOWEVER, if main_str is shorter than str, substr_compare checks only up
to the length of main_str. This is NOT how I read the description. I
believe the comparison should extend to length characters and render a
non-zero value if the two strings differ at any character in the first
length characters.
WORKAROUND: Use strncmp.
{Note that substr_compare advertises itself as "binary safe." Since it
is stopping at '\0', it fails to actually BE binary safe.}
Test script:
---
substr_compare("/", "/asd", 0, 4) => '
. substr_compare("/", "/asd", 0, 4)
. ' (SHOULD BE -3)'
. ' substr_compare("/asd", "/", 0, 4) => '
. substr_compare("/asd", "/", 0, 4)
. ' strncmp("/", "/asd", 4) => '
. strncmp("/", "/asd", 4)
. ' strncmp("/asd", "/", 4) => '
. strncmp("/asd", "/", 4); ?>
Expected result:
four comparisons of "/" and "/asd":
substr_compare("/", "/asd", 0, 4) => -3
substr_compare("/asd", "/", 0, 4) => 3
strncmp("/", "/asd", 4) => -3
strncmp("/asd", "/", 4) => 3
Actual result:
--
four comparisons of "/" and "/asd":
substr_compare("/", "/asd", 0, 4) => 0 (SHOULD BE -3)
substr_compare("/asd", "/", 0, 4) => 3
strncmp("/", "/asd", 4) => -3
strncmp("/asd", "/", 4) => 3
As the script says, the first reported value should be -3.
--
Edit this bug report at http://bugs.php.net/bug.php?id=54454&edit=1
Bug #54466 [Opn->Fbk]: Timezone offset for America/Caracas is wrong
Edit report at http://bugs.php.net/bug.php?id=54466&edit=1 ID: 54466 Updated by: ahar...@php.net Reported by:jose dot zap at gmail dot com Summary:Timezone offset for America/Caracas is wrong -Status: Open +Status: Feedback Type: Bug Package:Date/time related PHP Version:5.3.6 Block user comment: N Private report: N New Comment: I'm rather confused by your bug: DateTimeZone::listIdentifiers() doesn't list offsets, and the code that does appears to be correct on any recent PHP version: getOffset(new DateTime()) / 3600); ?> outputs float(-4.5), which lines up with your bug. What version of PHP are you running, what does phpinfo() list the Olson Timezone Database Version as, and what do you get when you run the above code? Previous Comments: [2011-04-04 17:38:48] jose dot zap at gmail dot com Description: When using DateTimeZone::listIdentifiers() the offset for America/Caracas is shown as GMT -5:30, when it should be GMT -4:30 This can be validated here http://www.timeanddate.com/library/abbreviations/timezones/sa/vet.html -- Edit this bug report at http://bugs.php.net/bug.php?id=54466&edit=1
Bug #54467 [Opn->Dup]: microseconds is always 000000
Edit report at http://bugs.php.net/bug.php?id=54467&edit=1
ID: 54467
Updated by: ahar...@php.net
Reported by:mark dot gustafson at hotmail dot com
Summary:microseconds is always 00
-Status: Open
+Status: Duplicate
Type: Bug
-Package:*General Issues
+Package:Date/time related
Operating System: Win2003K
PHP Version:5.3.6
Block user comment: N
Private report: N
New Comment:
Duplicate of bug #41806.
Previous Comments:
[2011-04-04 23:44:13] mark dot gustafson at hotmail dot com
small edit.
[2011-04-04 23:41:46] mark dot gustafson at hotmail dot com
Description:
I'm using Win2003K (fully patched), Apache 2.2.17 (Win32) and PHP
5.3.6.
Please run the following two lines in a PHP file:
$sTimeStamp = date("Y_m_d_H_i_s_u_");
print($sTimeStamp);
It will display as so:
2011_04_04_14_20_55_00_
Every time I run the file, the microseconds is always 00.
I hope this really is a bug and that you enjoy fixing it.
Thank You (!!!) and Best Regards.
Test script:
---
see above
Expected result:
see above
--
Edit this bug report at http://bugs.php.net/bug.php?id=54467&edit=1
