[PHP-BUG] Bug #64366 [NEW]: php fails to compile with mysq 5.6.x support
From: eugene at zhegan dot in Operating system: Solaris PHP version: 5.4.12 Package: Compile Failure Bug Type: Bug Bug description:php fails to compile with mysq 5.6.x support Description: PHP fails to compile with mysql 5.6.x support: /bin/sh /home/emz/src/php-5.4.12/libtool --silent --preserve-dup-deps -- mode=link /bin/gcc -export-dynamic -I/usr/include -m64 -O - I/usr/local/freetype/include -I/usr/local/mysql-5.6.10/include - I/usr/local/gmp/include -I/usr/local/openssl/include -I/usr/local/c- client/include -fvisibility=hidden -L/usr/ucblib -L/usr/gcc/4.5/lib/gcc/i386- pc-solaris2.11/4.5.2 -L/usr/local/openssl/lib -L/usr/local/libpng/lib - L/usr/local/mysql-5.6.10/lib -L/usr/local/mysql/lib -g -m64 -R /usr/ucblib -R /usr/gcc/4.5/lib/gcc/i386-pc-solaris2.11/4.5.2 -R /usr/local/openssl/lib -R /usr/local/libpng/lib -R /usr/local/mysql-5.6.10/lib -R /usr/local/mysql/lib Zend/zend_dtrace.d.o ext/date/php_date.lo ext/date/lib/astro.lo ext/date/lib/dow.lo ext/date/lib/parse_date.lo ext/date/lib/parse_tz.lo ext/date/lib/timelib.lo ext/date/lib/tm2unixtime.lo ext/date/lib/unixtime2tm.lo ext/date/lib/parse_iso_intervals.lo ext/date/lib/interval.lo ext/ereg/ereg.lo ext/ereg/regex/regcomp.lo ext/ereg/regex/regexec.lo ext/ereg/regex/regerror.lo ext/ereg/regex/regfree.lo ext/libxml/libxml.lo ext/pcre/pcrelib/pcre_chartables.lo ext/pcre/pcrelib/pcre_ucd.lo ext/pcre/pcrelib/pcre_compile.lo ext/pcre/pcrelib/pcre_config.lo ext/pcre/pcrelib/pcre_exec.lo ext/pcre/pcrelib/pcre_fullinfo.lo ext/pcre/pcrelib/pcre_get.lo ext/pcre/pcrelib/pcre_globals.lo ext/pcre/pcrelib/pcre_maketables.lo ext/pcre/pcrelib/pcre_newline.lo ext/pcre/pcrelib/pcre_ord2utf8.lo ext/pcre/pcrelib/pcre_refcount.lo ext/pcre/pcrelib/pcre_study.lo ext/pcre/pcrelib/pcre_tables.lo ext/pcre/pcrelib/pcre_valid_utf8.lo ext/pcre/pcrelib/pcre_version.lo ext/pcre/pcrelib/pcre_xclass.lo ext/pcre/php_pcre.lo ext/sqlite3/sqlite3.lo ext/sqlite3/libsqlite/sqlite3.lo ext/zlib/zlib.lo ext/zlib/zlib_fopen_wrapper.lo ext/zlib/zlib_filter.lo ext/bcmath/bcmath.lo ext/bcmath/libbcmath/src/add.lo ext/bcmath/libbcmath/src/div.lo ext/bcmath/libbcmath/src/init.lo ext/bcmath/libbcmath/src/neg.lo ext/bcmath/libbcmath/src/outofmem.lo ext/bcmath/libbcmath/src/raisemod.lo ext/bcmath/libbcmath/src/rt.lo ext/bcmath/libbcmath/src/sub.lo ext/bcmath/libbcmath/src/compare.lo ext/bcmath/libbcmath/src/divmod.lo ext/bcmath/libbcmath/src/int2num.lo ext/bcmath/libbcmath/src/num2long.lo ext/bcmath/libbcmath/src/output.lo ext/bcmath/libbcmath/src/recmul.lo ext/bcmath/libbcmath/src/sqrt.lo ext/bcmath/libbcmath/src/zero.lo ext/bcmath/libbcmath/src/debug.lo ext/bcmath/libbcmath/src/doaddsub.lo ext/bcmath/libbcmath/src/nearzero.lo ext/bcmath/libbcmath/src/num2str.lo ext/bcmath/libbcmath/src/raise.lo ext/bcmath/libbcmath/src/rmzero.lo ext/bcmath/libbcmath/src/str2num.lo ext/calendar/calendar.lo ext/calendar/dow.lo ext/calendar/french.lo ext/calendar/gregor.lo ext/calendar/jewish.lo ext/calendar/julian.lo ext/calendar/easter.lo ext/calendar/cal_unix.lo ext/ctype/ctype.lo ext/dom/php_dom.lo ext/dom/attr.lo ext/dom/document.lo ext/dom/domerrorhandler.lo ext/dom/domstringlist.lo ext/dom/domexception.lo ext/dom/namelist.lo ext/dom/processinginstruction.lo ext/dom/cdatasection.lo ext/dom/documentfragment.lo ext/dom/domimplementation.lo ext/dom/element.lo ext/dom/node.lo ext/dom/string_extend.lo ext/dom/characterdata.lo ext/dom/documenttype.lo ext/dom/domimplementationlist.lo ext/dom/entity.lo ext/dom/nodelist.lo ext/dom/text.lo ext/dom/comment.lo ext/dom/domconfiguration.lo ext/dom/domimplementationsource.lo ext/dom/entityreference.lo ext/dom/notation.lo ext/dom/xpath.lo ext/dom/dom_iterators.lo ext/dom/typeinfo.lo ext/dom/domerror.lo ext/dom/domlocator.lo ext/dom/namednodemap.lo ext/dom/userdatahandler.lo ext/fileinfo/fileinfo.lo ext/fileinfo/libmagic/apprentice.lo ext/fileinfo/libmagic/apptype.lo ext/fileinfo/libmagic/ascmagic.lo ext/fileinfo/libmagic/cdf.lo ext/fileinfo/libmagic/cdf_time.lo ext/fileinfo/libmagic/compress.lo ext/fileinfo/libmagic/encoding.lo ext/fileinfo/libmagic/fsmagic.lo ext/fileinfo/libmagic/funcs.lo ext/fileinfo/libmagic/is_tar.lo ext/fileinfo/libmagic/magic.lo ext/fileinfo/libmagic/print.lo ext/fileinfo/libmagic/readcdf.lo ext/fileinfo/libmagic/readelf.lo ext/fileinfo/libmagic/softmagic.lo ext/filter/filter.lo ext/filter/sanitizing_filters.lo ext/filter/logical_filters.lo ext/filter/callback_filter.lo ext/ftp/php_ftp.lo ext/ftp/ftp.lo ext/gd/gd.lo ext/gd/libgd/gd.lo ext/gd/libgd/gd_gd.lo ext/gd/libgd/gd_gd2.lo ext/gd/libgd/gd_io.lo ext/gd/libgd/gd_io_dp.lo ext/gd/libgd/gd_io_file.lo ext/gd/libgd/gd_ss.lo ext/gd/libgd/gd_io_ss.lo ext/gd/libgd/webpimg.lo ext/gd/libgd/gd_webp.lo ext/gd/libgd/gd_png.lo ext/gd/libgd/gd_jpeg.lo ext/gd/libgd/gdxpm.lo ext/gd/libgd/gdfontt.lo ext/gd/libgd/gdfonts.lo ext/gd/libgd/gdfontmb.lo ext/gd/libgd/gdfontl.lo ext/gd/libgd/gdfontg.lo ext/gd/libg
[PHP-BUG] Req #64367 [NEW]: localeconv() should respect ISO C99
From: abdevg at gmail dot com Operating system: Linux PHP version: 5.4.12 Package: Unknown/Other Function Bug Type: Feature/Change Request Bug description:localeconv() should respect ISO C99 Description: Locale data contain important information about currency formatting in fields int_p_sep_by_space and int_n_sep_by_space. C structure lconv contains such fields while PHP localeconv() doesn't return them. I've attached a patch but it probably should also contain something like #IFDEF USE_ISOC99 (sorry, I am not a C developer) Test script: --- set_locale(LC_MONETARY, 'en_US.UTF-8'); $lc = localeconv(); print $lc['int_p_sep_by_space']; Expected result: 1 Actual result: -- PHP Notice: Undefined index: int_p_sep_by_space -- Edit bug report at https://bugs.php.net/bug.php?id=64367&edit=1 -- Try a snapshot (PHP 5.4): https://bugs.php.net/fix.php?id=64367&r=trysnapshot54 Try a snapshot (PHP 5.3): https://bugs.php.net/fix.php?id=64367&r=trysnapshot53 Try a snapshot (trunk): https://bugs.php.net/fix.php?id=64367&r=trysnapshottrunk Fixed in SVN: https://bugs.php.net/fix.php?id=64367&r=fixed Fixed in release: https://bugs.php.net/fix.php?id=64367&r=alreadyfixed Need backtrace: https://bugs.php.net/fix.php?id=64367&r=needtrace Need Reproduce Script: https://bugs.php.net/fix.php?id=64367&r=needscript Try newer version: https://bugs.php.net/fix.php?id=64367&r=oldversion Not developer issue:https://bugs.php.net/fix.php?id=64367&r=support Expected behavior: https://bugs.php.net/fix.php?id=64367&r=notwrong Not enough info: https://bugs.php.net/fix.php?id=64367&r=notenoughinfo Submitted twice: https://bugs.php.net/fix.php?id=64367&r=submittedtwice register_globals: https://bugs.php.net/fix.php?id=64367&r=globals PHP 4 support discontinued: https://bugs.php.net/fix.php?id=64367&r=php4 Daylight Savings: https://bugs.php.net/fix.php?id=64367&r=dst IIS Stability: https://bugs.php.net/fix.php?id=64367&r=isapi Install GNU Sed:https://bugs.php.net/fix.php?id=64367&r=gnused Floating point limitations: https://bugs.php.net/fix.php?id=64367&r=float No Zend Extensions: https://bugs.php.net/fix.php?id=64367&r=nozend MySQL Configuration Error: https://bugs.php.net/fix.php?id=64367&r=mysqlcfg
Req #64359 [Opn]: strftime crash with php/vc11
Edit report at https://bugs.php.net/bug.php?id=64359&edit=1
ID: 64359
Updated by: a...@php.net
Reported by:a...@php.net
Summary:strftime crash with php/vc11
Status: Open
Type: Feature/Change Request
Package:Date/time related
Operating System: Windows
PHP Version:Irrelevant
Block user comment: N
Private report: N
New Comment:
vc9/o+ can be ignored. The cause of this issue a bug in vc11 crt. Here is the
ticket from the MS knowledge base
http://connect.microsoft.com/VisualStudio/feedback/details/759720/vs2012-strftime-crash-with-z-formatting-code
The crash is caused only by %z and %Z formats. Here are two simple snippets
strftime(str_repeat('%z', 1), mktime(0,0,0, 6, 27, 2013)); /* crash */
strftime(str_repeat('%B', 1), mktime(0,0,0, 6, 27, 2013)); /* bool(false) */
Previous Comments:
[2013-03-05 18:16:58] a...@php.net
Description:
PHP crashes only when compiled with VC11. I could track it back with 5.4.1
compiled with VC11. Another not obvious crash happens with 5.5/VC9 using O+.
Here's the backtrace 5.5/VC11:
msvcr110d.dll!_invoke_watson(const wchar_t * pszExpression, const wchar_t *
pszFunction, const wchar_t * pszFile, unsigned int nLine, unsigned int
pReserved) Line 131C++
msvcr110d.dll!_invoke_watson_if_error(int _ExpressionError, const wchar_t *
_Expression, const wchar_t * _Function, const wchar_t * _File, unsigned int
_Line, unsigned int _Reserved) Line 730C
msvcr110d.dll!_W_expandtime(localeinfo_struct * plocinfo, wchar_t specifier,
const tm * timeptr, wchar_t * * string, unsigned int * left, __lc_time_data *
lc_time, unsigned int alternate_form) Line 722C++
msvcr110d.dll!_Wcsftime_l(wchar_t * string, unsigned int maxsize, const
wchar_t * format, const tm * timeptr, void * lc_time_arg, localeinfo_struct *
plocinfo) Line 323C++
msvcr110d.dll!_Strftime_l(char * string, unsigned int maxsize, const char *
format, const tm * timeptr, void * lc_time_arg, localeinfo_struct * plocinfo)
Line 285C++
msvcr110d.dll!strftime(char * string, unsigned int maxsize, const char *
format, const tm * timeptr) Line 189C++
php5_debug.dll!php_strftime(int ht, _zval_struct * return_value, _zval_struct
* * return_value_ptr, _zval_struct * this_ptr, int return_value_used, int gmt)
Line 1631C
php5_debug.dll!zif_strftime(int ht, _zval_struct * return_value, _zval_struct
* * return_value_ptr, _zval_struct * this_ptr, int return_value_used) Line 1657C
php5_debug.dll!zend_do_fcall_common_helper_SPEC(_zend_execute_data *
execute_data) Line 542C
php5_debug.dll!ZEND_DO_FCALL_SPEC_CONST_HANDLER(_zend_execute_data *
execute_data) Line 2321C
php5_debug.dll!execute_ex(_zend_execute_data * execute_data) Line 356C
php5_debug.dll!zend_execute(_zend_op_array * op_array) Line 381C
php5_debug.dll!zend_eval_stringl(char * str, int str_len, _zval_struct *
retval_ptr, char * string_name) Line 1181C
php5_debug.dll!zend_eval_stringl_ex(char * str, int str_len, _zval_struct *
retval_ptr, char * string_name, int handle_exceptions) Line 1228C
php5_debug.dll!zend_eval_string_ex(char * str, _zval_struct * retval_ptr, char
* string_name, int handle_exceptions) Line 1239C
php.exe!do_cli(int argc, char * * argv) Line 1028C
php.exe!main(int argc, char * * argv) Line 1364C
php.exe!__tmainCRTStartup() Line 536C
php.exe!mainCRTStartup() Line 377C
kernel32.dll!@BaseThreadInitThunk@12 ()Unknown
ntdll.dll!___RtlUserThreadStart@8 ()Unknown
ntdll.dll!__RtlUserThreadStart@8 ()Unknown
Test script:
---
ext/date/tests/009_win32.phpt
or this snippet
var_dump(strftime('%a %A %b %B %c %d %H %I %j %m %M %p %S %U %W %w %x %X %y %Y
%Z %z %%', mktime(0,0,0, 6, 27, 2013)));
Expected result:
no crash
Actual result:
--
PHP crash
--
Edit this bug report at https://bugs.php.net/bug.php?id=64359&edit=1
Req #64359 [Opn->Csd]: strftime crash with php/vc11
Edit report at https://bugs.php.net/bug.php?id=64359&edit=1
ID: 64359
Updated by: a...@php.net
Reported by:a...@php.net
Summary:strftime crash with php/vc11
-Status: Open
+Status: Closed
Type: Feature/Change Request
Package:Date/time related
Operating System: Windows
PHP Version:Irrelevant
Block user comment: N
Private report: N
New Comment:
Automatic comment on behalf of ab
Revision:
http://git.php.net/?p=php-src.git;a=commit;h=371000a877c91cfc11ff3c75ce83826797478569
Log: Fixed bug #64359 strftime crash with VS2012
Previous Comments:
[2013-03-06 09:29:44] a...@php.net
vc9/o+ can be ignored. The cause of this issue a bug in vc11 crt. Here is the
ticket from the MS knowledge base
http://connect.microsoft.com/VisualStudio/feedback/details/759720/vs2012-strftime-crash-with-z-formatting-code
The crash is caused only by %z and %Z formats. Here are two simple snippets
strftime(str_repeat('%z', 1), mktime(0,0,0, 6, 27, 2013)); /* crash */
strftime(str_repeat('%B', 1), mktime(0,0,0, 6, 27, 2013)); /* bool(false) */
[2013-03-05 18:16:58] a...@php.net
Description:
PHP crashes only when compiled with VC11. I could track it back with 5.4.1
compiled with VC11. Another not obvious crash happens with 5.5/VC9 using O+.
Here's the backtrace 5.5/VC11:
msvcr110d.dll!_invoke_watson(const wchar_t * pszExpression, const wchar_t *
pszFunction, const wchar_t * pszFile, unsigned int nLine, unsigned int
pReserved) Line 131C++
msvcr110d.dll!_invoke_watson_if_error(int _ExpressionError, const wchar_t *
_Expression, const wchar_t * _Function, const wchar_t * _File, unsigned int
_Line, unsigned int _Reserved) Line 730C
msvcr110d.dll!_W_expandtime(localeinfo_struct * plocinfo, wchar_t specifier,
const tm * timeptr, wchar_t * * string, unsigned int * left, __lc_time_data *
lc_time, unsigned int alternate_form) Line 722C++
msvcr110d.dll!_Wcsftime_l(wchar_t * string, unsigned int maxsize, const
wchar_t * format, const tm * timeptr, void * lc_time_arg, localeinfo_struct *
plocinfo) Line 323C++
msvcr110d.dll!_Strftime_l(char * string, unsigned int maxsize, const char *
format, const tm * timeptr, void * lc_time_arg, localeinfo_struct * plocinfo)
Line 285C++
msvcr110d.dll!strftime(char * string, unsigned int maxsize, const char *
format, const tm * timeptr) Line 189C++
php5_debug.dll!php_strftime(int ht, _zval_struct * return_value, _zval_struct
* * return_value_ptr, _zval_struct * this_ptr, int return_value_used, int gmt)
Line 1631C
php5_debug.dll!zif_strftime(int ht, _zval_struct * return_value, _zval_struct
* * return_value_ptr, _zval_struct * this_ptr, int return_value_used) Line 1657C
php5_debug.dll!zend_do_fcall_common_helper_SPEC(_zend_execute_data *
execute_data) Line 542C
php5_debug.dll!ZEND_DO_FCALL_SPEC_CONST_HANDLER(_zend_execute_data *
execute_data) Line 2321C
php5_debug.dll!execute_ex(_zend_execute_data * execute_data) Line 356C
php5_debug.dll!zend_execute(_zend_op_array * op_array) Line 381C
php5_debug.dll!zend_eval_stringl(char * str, int str_len, _zval_struct *
retval_ptr, char * string_name) Line 1181C
php5_debug.dll!zend_eval_stringl_ex(char * str, int str_len, _zval_struct *
retval_ptr, char * string_name, int handle_exceptions) Line 1228C
php5_debug.dll!zend_eval_string_ex(char * str, _zval_struct * retval_ptr, char
* string_name, int handle_exceptions) Line 1239C
php.exe!do_cli(int argc, char * * argv) Line 1028C
php.exe!main(int argc, char * * argv) Line 1364C
php.exe!__tmainCRTStartup() Line 536C
php.exe!mainCRTStartup() Line 377C
kernel32.dll!@BaseThreadInitThunk@12 ()Unknown
ntdll.dll!___RtlUserThreadStart@8 ()Unknown
ntdll.dll!__RtlUserThreadStart@8 ()Unknown
Test script:
---
ext/date/tests/009_win32.phpt
or this snippet
var_dump(strftime('%a %A %b %B %c %d %H %I %j %m %M %p %S %U %W %w %x %X %y %Y
%Z %z %%', mktime(0,0,0, 6, 27, 2013)));
Expected result:
no crash
Actual result:
--
PHP crash
--
Edit this bug report at https://bugs.php.net/bug.php?id=64359&edit=1
Bug #33957 [Com]: gmdate('W')/date('W') sometimes returns wrong week number.
Edit report at https://bugs.php.net/bug.php?id=33957&edit=1
ID: 33957
Comment by: tchorbadjiiski at gmail dot com
Reported by:paul at stunning-stuff dot com
Summary:gmdate('W')/date('W') sometimes returns wrong week
number.
Status: Closed
Type: Bug
Package:Date/time related
Operating System: *
PHP Version:5CVS-2005-08-02
Assigned To:derick
Block user comment: N
Private report: N
New Comment:
Hello,
it seems that this bug is still alive:-). My tries to calculate the week for
timestamps belonging to 31 December 2012 are returning the wrong result as can
be seen here:
date('Y/W', 1356908400) => 2012/01
date('Y/m/d H:i:s', 1356908400) => 2012/12/31 00:00:00
Calls with timestamps belonging to 30/12/12 or 01/01/13 result in the correct
output.
Expected behavior (for me reading the ISO 8601 doc) would be to have the year
2013 in the first call to the date function.
I'm using debian wheezy (testing) with the following php version:
PHP 5.4.4-13 (cli) (built: Feb 19 2013 10:54:11)
Thanks and cheers,
Angel Tchorbadjiiski
Previous Comments:
[2010-06-14 09:03:34] paul at stunning-stuff dot com
23 is the correct week number according to timeanddate.com. Remember the week
number is determined using ISO8601 rules!!
Btw, a snapshot release is an 'overnight' release of the latest version of a
software package. Google will tell you more.
-Paul
[2010-06-13 13:07:20] cgullz at gmail dot com
Hi,
I have the same problem using date('W') to show week number of 13/June/2010
which should be 25, but it displays 23.
I use php 5.2.6 through WAMP2.
This is the first time I hear about snapshot so not sure what am I suppose to
do to fix this problem.
Can someone please explain to me what should I do?
Thank you,
Sigal
[2010-05-19 20:56:04] paul at stunning-stuff dot com
Hi Warwick,
The 1st week of a year does not necessarily start on the first of January
under the rules of ISO8601. I checked your examples and they seemed fine.
Please read up on ISO8601.
-Paul
[2010-05-19 04:06:11] wps at wwe dot com
date('W', $timestamp) fails to return "01" for some January 1st years on PHP
version 5.3.2 and 5.2.8 on CentOS and Windows.
$year = 1970;
$month = 1;
$day = 1;
while ($year <= 2028) {
$timestamp = mktime(12, 0, 0, $month, $day, $year);
print $year . " :: " . date('W', $timestamp). " :: " . date('D', $timestamp)
. "\n";
$year++;
}
Expect 01 for every year
but instead get
1970 :: 01 :: Thu
1971 :: 53 :: Fri
1972 :: 52 :: Sat
1973 :: 01 :: Mon
1974 :: 01 :: Tue
1975 :: 01 :: Wed
1976 :: 01 :: Thu
1977 :: 53 :: Sat
1978 :: 52 :: Sun
...
2020 :: 01 :: Wed
2021 :: 53 :: Fri
2022 :: 52 :: Sat
2023 :: 52 :: Sun
2024 :: 01 :: Mon
2025 :: 01 :: Wed
2026 :: 01 :: Thu
2027 :: 53 :: Fri
2028 :: 52 :: Sat
1st falling on Friday returns 53
1st falling on Saturday/Sunday return 52
Checked dates using
http://www.tuxgraphics.org/toolbox/cal_year.html
Warwick Shaw
[2005-08-31 16:31:52] der...@php.net
This bug has been fixed in CVS.
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.
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=33957
--
Edit this bug report at https://bugs.php.net/bug.php?id=33957&edit=1
[PHP-BUG] Bug #64369 [NEW]: strtotime() doesn't return false for some invalid formats
From: gen dot work at gmail dot com
Operating system: Ubuntu 12.10
PHP version: 5.4.12
Package: Date/time related
Bug Type: Bug
Bug description:strtotime() doesn't return false for some invalid formats
Description:
strtotime() doesn't return false for some invalid formats.
Test script:
---
var_dump(strtotime('invalid_string'));
var_dump(strtotime('-1 monthZ'));
var_dump(strtotime('-1 monthsx'));
Expected result:
bool(false)
bool(false)
bool(false)
Actual result:
--
bool(false)
int(1360161652)
int(1360201252)
--
Edit bug report at https://bugs.php.net/bug.php?id=64369&edit=1
--
Try a snapshot (PHP 5.4):
https://bugs.php.net/fix.php?id=64369&r=trysnapshot54
Try a snapshot (PHP 5.3):
https://bugs.php.net/fix.php?id=64369&r=trysnapshot53
Try a snapshot (trunk):
https://bugs.php.net/fix.php?id=64369&r=trysnapshottrunk
Fixed in SVN: https://bugs.php.net/fix.php?id=64369&r=fixed
Fixed in release: https://bugs.php.net/fix.php?id=64369&r=alreadyfixed
Need backtrace: https://bugs.php.net/fix.php?id=64369&r=needtrace
Need Reproduce Script: https://bugs.php.net/fix.php?id=64369&r=needscript
Try newer version: https://bugs.php.net/fix.php?id=64369&r=oldversion
Not developer issue:https://bugs.php.net/fix.php?id=64369&r=support
Expected behavior: https://bugs.php.net/fix.php?id=64369&r=notwrong
Not enough info:
https://bugs.php.net/fix.php?id=64369&r=notenoughinfo
Submitted twice:
https://bugs.php.net/fix.php?id=64369&r=submittedtwice
register_globals: https://bugs.php.net/fix.php?id=64369&r=globals
PHP 4 support discontinued: https://bugs.php.net/fix.php?id=64369&r=php4
Daylight Savings: https://bugs.php.net/fix.php?id=64369&r=dst
IIS Stability: https://bugs.php.net/fix.php?id=64369&r=isapi
Install GNU Sed:https://bugs.php.net/fix.php?id=64369&r=gnused
Floating point limitations: https://bugs.php.net/fix.php?id=64369&r=float
No Zend Extensions: https://bugs.php.net/fix.php?id=64369&r=nozend
MySQL Configuration Error: https://bugs.php.net/fix.php?id=64369&r=mysqlcfg
Bug #64369 [Opn->Nab]: strtotime() doesn't return false for some invalid formats
Edit report at https://bugs.php.net/bug.php?id=64369&edit=1
ID: 64369
Updated by: der...@php.net
Reported by:gen dot work at gmail dot com
Summary:strtotime() doesn't return false for some invalid
formats
-Status: Open
+Status: Not a bug
Type: Bug
Package:Date/time related
Operating System: Ubuntu 12.10
PHP Version:5.4.12
Block user comment: N
Private report: N
New Comment:
Thank you for taking the time to write to us, but this is not
a bug. Please double-check the documentation available at
http://www.php.net/manual/ and the instructions on how to report
a bug at http://bugs.php.net/how-to-report.php
That is because they are not invalid. "Z" is a timezone abbreviation:
derick@whisky:~ $ php -r 'var_dump(date_parse("-1 monthZ"));'
array(17) {
'year' =>
bool(false)
'month' =>
bool(false)
'day' =>
bool(false)
'hour' =>
bool(false)
'minute' =>
bool(false)
'second' =>
bool(false)
'fraction' =>
bool(false)
'warning_count' =>
int(0)
'warnings' =>
array(0) {
}
'error_count' =>
int(0)
'errors' =>
array(0) {
}
'is_localtime' =>
bool(true)
'zone_type' =>
int(2)
'zone' =>
int(0)
'is_dst' =>
bool(false)
'tz_abbr' =>
string(1) "Z"
'relative' =>
array(6) {
'year' =>
int(0)
'month' =>
int(-1)
'day' =>
int(0)
'hour' =>
int(0)
'minute' =>
int(0)
'second' =>
int(0)
}
}
And "SX" is (monthS + X), with X also be a timezone abbreviation:
derick@whisky:~ $ php -r 'var_dump(date_parse("-1 monthsx"));'
array(17) {
'year' =>
bool(false)
'month' =>
bool(false)
'day' =>
bool(false)
'hour' =>
bool(false)
'minute' =>
bool(false)
'second' =>
bool(false)
'fraction' =>
bool(false)
'warning_count' =>
int(0)
'warnings' =>
array(0) {
}
'error_count' =>
int(0)
'errors' =>
array(0) {
}
'is_localtime' =>
bool(true)
'zone_type' =>
int(2)
'zone' =>
int(660)
'is_dst' =>
bool(false)
'tz_abbr' =>
string(1) "X"
'relative' =>
array(6) {
'year' =>
int(0)
'month' =>
int(-1)
'day' =>
int(0)
'hour' =>
int(0)
'minute' =>
int(0)
'second' =>
int(0)
}
}
Previous Comments:
[2013-03-06 13:47:17] gen dot work at gmail dot com
Description:
strtotime() doesn't return false for some invalid formats.
Test script:
---
var_dump(strtotime('invalid_string'));
var_dump(strtotime('-1 monthZ'));
var_dump(strtotime('-1 monthsx'));
Expected result:
bool(false)
bool(false)
bool(false)
Actual result:
--
bool(false)
int(1360161652)
int(1360201252)
--
Edit this bug report at https://bugs.php.net/bug.php?id=64369&edit=1
Bug #64369 [Nab]: strtotime() doesn't return false for some invalid formats
Edit report at https://bugs.php.net/bug.php?id=64369&edit=1
ID: 64369
User updated by:gen dot work at gmail dot com
Reported by:gen dot work at gmail dot com
Summary:strtotime() doesn't return false for some invalid
formats
Status: Not a bug
Type: Bug
Package:Date/time related
Operating System: Ubuntu 12.10
PHP Version:5.4.12
Block user comment: N
Private report: N
New Comment:
Then following this logic '-1 months' should be parsed as 1 month + S, where S
is a timezone abbreviation?
Previous Comments:
[2013-03-06 14:30:26] der...@php.net
Thank you for taking the time to write to us, but this is not
a bug. Please double-check the documentation available at
http://www.php.net/manual/ and the instructions on how to report
a bug at http://bugs.php.net/how-to-report.php
That is because they are not invalid. "Z" is a timezone abbreviation:
derick@whisky:~ $ php -r 'var_dump(date_parse("-1 monthZ"));'
array(17) {
'year' =>
bool(false)
'month' =>
bool(false)
'day' =>
bool(false)
'hour' =>
bool(false)
'minute' =>
bool(false)
'second' =>
bool(false)
'fraction' =>
bool(false)
'warning_count' =>
int(0)
'warnings' =>
array(0) {
}
'error_count' =>
int(0)
'errors' =>
array(0) {
}
'is_localtime' =>
bool(true)
'zone_type' =>
int(2)
'zone' =>
int(0)
'is_dst' =>
bool(false)
'tz_abbr' =>
string(1) "Z"
'relative' =>
array(6) {
'year' =>
int(0)
'month' =>
int(-1)
'day' =>
int(0)
'hour' =>
int(0)
'minute' =>
int(0)
'second' =>
int(0)
}
}
And "SX" is (monthS + X), with X also be a timezone abbreviation:
derick@whisky:~ $ php -r 'var_dump(date_parse("-1 monthsx"));'
array(17) {
'year' =>
bool(false)
'month' =>
bool(false)
'day' =>
bool(false)
'hour' =>
bool(false)
'minute' =>
bool(false)
'second' =>
bool(false)
'fraction' =>
bool(false)
'warning_count' =>
int(0)
'warnings' =>
array(0) {
}
'error_count' =>
int(0)
'errors' =>
array(0) {
}
'is_localtime' =>
bool(true)
'zone_type' =>
int(2)
'zone' =>
int(660)
'is_dst' =>
bool(false)
'tz_abbr' =>
string(1) "X"
'relative' =>
array(6) {
'year' =>
int(0)
'month' =>
int(-1)
'day' =>
int(0)
'hour' =>
int(0)
'minute' =>
int(0)
'second' =>
int(0)
}
}
[2013-03-06 13:47:17] gen dot work at gmail dot com
Description:
strtotime() doesn't return false for some invalid formats.
Test script:
---
var_dump(strtotime('invalid_string'));
var_dump(strtotime('-1 monthZ'));
var_dump(strtotime('-1 monthsx'));
Expected result:
bool(false)
bool(false)
bool(false)
Actual result:
--
bool(false)
int(1360161652)
int(1360201252)
--
Edit this bug report at https://bugs.php.net/bug.php?id=64369&edit=1
[PHP-BUG] Bug #64370 [NEW]: microtime(true) corrupted
From: bugzilla77 at gmail dot com Operating system: win 7 (32/64) PHP version: 5.5.0alpha5 Package: Date/time related Bug Type: Bug Bug description:microtime(true) corrupted Description: microtime(true) returns value less than time() (or $_SERVER['REQUEST_TIME'] or $_SERVER['REQUEST_TIME_FLOAT']) up to a DOZEN seconds!!! live demo: http://pulsmedica.com.pl/microtime.php win 7 32bit apache 2.4.3 + php5apache2_4.dll php 5.5a5 ts Test script: --- $_SERVER['REQUEST_TIME']: $_SERVER['REQUEST_TIME_FLOAT']: time(): microtime(true): PHP created in ms Expected result: PHP 5.4: never problems Actual result: -- PHP 5.5 live demo: http://pulsmedica.com.pl/microtime.php -- Edit bug report at https://bugs.php.net/bug.php?id=64370&edit=1 -- Try a snapshot (PHP 5.4): https://bugs.php.net/fix.php?id=64370&r=trysnapshot54 Try a snapshot (PHP 5.3): https://bugs.php.net/fix.php?id=64370&r=trysnapshot53 Try a snapshot (trunk): https://bugs.php.net/fix.php?id=64370&r=trysnapshottrunk Fixed in SVN: https://bugs.php.net/fix.php?id=64370&r=fixed Fixed in release: https://bugs.php.net/fix.php?id=64370&r=alreadyfixed Need backtrace: https://bugs.php.net/fix.php?id=64370&r=needtrace Need Reproduce Script: https://bugs.php.net/fix.php?id=64370&r=needscript Try newer version: https://bugs.php.net/fix.php?id=64370&r=oldversion Not developer issue:https://bugs.php.net/fix.php?id=64370&r=support Expected behavior: https://bugs.php.net/fix.php?id=64370&r=notwrong Not enough info: https://bugs.php.net/fix.php?id=64370&r=notenoughinfo Submitted twice: https://bugs.php.net/fix.php?id=64370&r=submittedtwice register_globals: https://bugs.php.net/fix.php?id=64370&r=globals PHP 4 support discontinued: https://bugs.php.net/fix.php?id=64370&r=php4 Daylight Savings: https://bugs.php.net/fix.php?id=64370&r=dst IIS Stability: https://bugs.php.net/fix.php?id=64370&r=isapi Install GNU Sed:https://bugs.php.net/fix.php?id=64370&r=gnused Floating point limitations: https://bugs.php.net/fix.php?id=64370&r=float No Zend Extensions: https://bugs.php.net/fix.php?id=64370&r=nozend MySQL Configuration Error: https://bugs.php.net/fix.php?id=64370&r=mysqlcfg
Bug #64369 [Nab]: strtotime() doesn't return false for some invalid formats
Edit report at https://bugs.php.net/bug.php?id=64369&edit=1
ID: 64369
Updated by: der...@php.net
Reported by:gen dot work at gmail dot com
Summary:strtotime() doesn't return false for some invalid
formats
Status: Not a bug
Type: Bug
Package:Date/time related
Operating System: Ubuntu 12.10
PHP Version:5.4.12
Block user comment: N
Private report: N
New Comment:
"months" alone is a variant keyword for "month", so no.
Previous Comments:
[2013-03-06 15:28:32] gen dot work at gmail dot com
Then following this logic '-1 months' should be parsed as 1 month + S, where S
is a timezone abbreviation?
[2013-03-06 14:30:26] der...@php.net
Thank you for taking the time to write to us, but this is not
a bug. Please double-check the documentation available at
http://www.php.net/manual/ and the instructions on how to report
a bug at http://bugs.php.net/how-to-report.php
That is because they are not invalid. "Z" is a timezone abbreviation:
derick@whisky:~ $ php -r 'var_dump(date_parse("-1 monthZ"));'
array(17) {
'year' =>
bool(false)
'month' =>
bool(false)
'day' =>
bool(false)
'hour' =>
bool(false)
'minute' =>
bool(false)
'second' =>
bool(false)
'fraction' =>
bool(false)
'warning_count' =>
int(0)
'warnings' =>
array(0) {
}
'error_count' =>
int(0)
'errors' =>
array(0) {
}
'is_localtime' =>
bool(true)
'zone_type' =>
int(2)
'zone' =>
int(0)
'is_dst' =>
bool(false)
'tz_abbr' =>
string(1) "Z"
'relative' =>
array(6) {
'year' =>
int(0)
'month' =>
int(-1)
'day' =>
int(0)
'hour' =>
int(0)
'minute' =>
int(0)
'second' =>
int(0)
}
}
And "SX" is (monthS + X), with X also be a timezone abbreviation:
derick@whisky:~ $ php -r 'var_dump(date_parse("-1 monthsx"));'
array(17) {
'year' =>
bool(false)
'month' =>
bool(false)
'day' =>
bool(false)
'hour' =>
bool(false)
'minute' =>
bool(false)
'second' =>
bool(false)
'fraction' =>
bool(false)
'warning_count' =>
int(0)
'warnings' =>
array(0) {
}
'error_count' =>
int(0)
'errors' =>
array(0) {
}
'is_localtime' =>
bool(true)
'zone_type' =>
int(2)
'zone' =>
int(660)
'is_dst' =>
bool(false)
'tz_abbr' =>
string(1) "X"
'relative' =>
array(6) {
'year' =>
int(0)
'month' =>
int(-1)
'day' =>
int(0)
'hour' =>
int(0)
'minute' =>
int(0)
'second' =>
int(0)
}
}
[2013-03-06 13:47:17] gen dot work at gmail dot com
Description:
strtotime() doesn't return false for some invalid formats.
Test script:
---
var_dump(strtotime('invalid_string'));
var_dump(strtotime('-1 monthZ'));
var_dump(strtotime('-1 monthsx'));
Expected result:
bool(false)
bool(false)
bool(false)
Actual result:
--
bool(false)
int(1360161652)
int(1360201252)
--
Edit this bug report at https://bugs.php.net/bug.php?id=64369&edit=1
Bug #64369 [Nab]: strtotime() doesn't return false for some invalid formats
Edit report at https://bugs.php.net/bug.php?id=64369&edit=1
ID: 64369
User updated by:gen dot work at gmail dot com
Reported by:gen dot work at gmail dot com
Summary:strtotime() doesn't return false for some invalid
formats
Status: Not a bug
Type: Bug
Package:Date/time related
Operating System: Ubuntu 12.10
PHP Version:5.4.12
Block user comment: N
Private report: N
New Comment:
True, but this means that for timezone abbreviation "Z" you simply put "1
monthZ", but for "S" you have to write "1 monthsS", which is not so obvious.
Previous Comments:
[2013-03-06 15:49:42] der...@php.net
"months" alone is a variant keyword for "month", so no.
[2013-03-06 15:28:32] gen dot work at gmail dot com
Then following this logic '-1 months' should be parsed as 1 month + S, where S
is a timezone abbreviation?
[2013-03-06 14:30:26] der...@php.net
Thank you for taking the time to write to us, but this is not
a bug. Please double-check the documentation available at
http://www.php.net/manual/ and the instructions on how to report
a bug at http://bugs.php.net/how-to-report.php
That is because they are not invalid. "Z" is a timezone abbreviation:
derick@whisky:~ $ php -r 'var_dump(date_parse("-1 monthZ"));'
array(17) {
'year' =>
bool(false)
'month' =>
bool(false)
'day' =>
bool(false)
'hour' =>
bool(false)
'minute' =>
bool(false)
'second' =>
bool(false)
'fraction' =>
bool(false)
'warning_count' =>
int(0)
'warnings' =>
array(0) {
}
'error_count' =>
int(0)
'errors' =>
array(0) {
}
'is_localtime' =>
bool(true)
'zone_type' =>
int(2)
'zone' =>
int(0)
'is_dst' =>
bool(false)
'tz_abbr' =>
string(1) "Z"
'relative' =>
array(6) {
'year' =>
int(0)
'month' =>
int(-1)
'day' =>
int(0)
'hour' =>
int(0)
'minute' =>
int(0)
'second' =>
int(0)
}
}
And "SX" is (monthS + X), with X also be a timezone abbreviation:
derick@whisky:~ $ php -r 'var_dump(date_parse("-1 monthsx"));'
array(17) {
'year' =>
bool(false)
'month' =>
bool(false)
'day' =>
bool(false)
'hour' =>
bool(false)
'minute' =>
bool(false)
'second' =>
bool(false)
'fraction' =>
bool(false)
'warning_count' =>
int(0)
'warnings' =>
array(0) {
}
'error_count' =>
int(0)
'errors' =>
array(0) {
}
'is_localtime' =>
bool(true)
'zone_type' =>
int(2)
'zone' =>
int(660)
'is_dst' =>
bool(false)
'tz_abbr' =>
string(1) "X"
'relative' =>
array(6) {
'year' =>
int(0)
'month' =>
int(-1)
'day' =>
int(0)
'hour' =>
int(0)
'minute' =>
int(0)
'second' =>
int(0)
}
}
[2013-03-06 13:47:17] gen dot work at gmail dot com
Description:
strtotime() doesn't return false for some invalid formats.
Test script:
---
var_dump(strtotime('invalid_string'));
var_dump(strtotime('-1 monthZ'));
var_dump(strtotime('-1 monthsx'));
Expected result:
bool(false)
bool(false)
bool(false)
Actual result:
--
bool(false)
int(1360161652)
int(1360201252)
--
Edit this bug report at https://bugs.php.net/bug.php?id=64369&edit=1
Bug #64366 [Opn->Fbk]: php fails to compile with mysq 5.6.x support
Edit report at https://bugs.php.net/bug.php?id=64366&edit=1 ID: 64366 Updated by: johan...@php.net Reported by:eugene at zhegan dot in Summary:php fails to compile with mysq 5.6.x support -Status: Open +Status: Feedback Type: Bug Package:Compile Failure Operating System: Solaris PHP Version:5.4.12 Block user comment: N Private report: N New Comment: Without looking deeper there are some confusing things about your configuration: 1) ld: warning: file /usr/gcc/4.5/lib/gcc/i386-pc- solaris2.11/4.5.2/libgcc_eh.a(unwind-dw2.o): wrong ELF class: ELFCLASS32 Thnis indicates you're mixing 32 and 64 bit code. So some of the libraries you're trying to pull in seem to be 32 bit, whiel you'Ve added -m64 to the CFLAGS. n case you have fetched MySQL from mysql.com be sure to use the 64bit version when using -m64. 2) --with-mysql=/usr/local/mysql-5.6.10 \ --with-mysqli \ --with-pdo-mysql=/usr/local/mysql --with-pdo-mysql=/usr/local/mysql These are contradicting each other. ext/mysql is being compiled and linked against MySQL from /usr/local/mysql-5.6.10, mysqli is using mysqlnd, PDO_mysql is using /usr/local/mysql. You should stick to one. Suggested is usage of mysqlnd therefore simply using --with-mysql --with-mysqli --with-pdo-mysql 3) CFLAGS="-m64 -O -I/usr/local/freetype/include -I/usr/local/mysql-5.6.10/include -I/usr/local/gmp/include -I/usr/local/openssl/include -I/usr/local/c- client/include" LDFLAGS="-R/usr/gcc/4.5/lib/amd64 -L/usr/gcc/4.5/lib/amd64 - R/usr/gcc/4.5/lib/gcc/i386-pc-solaris2.11/4.5.2/amd64 -L/usr /gcc/4.5/lib/gcc/i386-pc-solaris2.11/4.5.2/amd64 -L/usr/local/mysql- 5.6.10/lib/mysql -L/usr/local/gmp/lib -L/usr/local/openssl/lib -L/usr/local/c- client/lib -lstdc++" Most of these paths shouldn't be set manually. Adding -lstdc++ is a bad choice. Except when using the intl extension there should be no C++ in PHP. In case external libraries make use of C++ they should pull in the C++ lib they need. Usually system libraries and MySQL builds by Oracle use Solaris Studio (aka Sun studio) compilers, not gcc. libstdc++ is gcc-specific, though. If there is need to pull in that lib this should happen not by explicitly linking in that lib but by linking using $CXX, not $CC If those hints don't help please reduce the configure line to the minimum options needed for it to break n provide `uname -a` info so we can try to reproduce it. Previous Comments: [2013-03-06 08:12:00] eugene at zhegan dot in Description: PHP fails to compile with mysql 5.6.x support: /bin/sh /home/emz/src/php-5.4.12/libtool --silent --preserve-dup-deps -- mode=link /bin/gcc -export-dynamic -I/usr/include -m64 -O - I/usr/local/freetype/include -I/usr/local/mysql-5.6.10/include - I/usr/local/gmp/include -I/usr/local/openssl/include -I/usr/local/c- client/include -fvisibility=hidden -L/usr/ucblib -L/usr/gcc/4.5/lib/gcc/i386- pc-solaris2.11/4.5.2 -L/usr/local/openssl/lib -L/usr/local/libpng/lib - L/usr/local/mysql-5.6.10/lib -L/usr/local/mysql/lib -g -m64 -R /usr/ucblib -R /usr/gcc/4.5/lib/gcc/i386-pc-solaris2.11/4.5.2 -R /usr/local/openssl/lib -R /usr/local/libpng/lib -R /usr/local/mysql-5.6.10/lib -R /usr/local/mysql/lib Zend/zend_dtrace.d.o ext/date/php_date.lo ext/date/lib/astro.lo ext/date/lib/dow.lo ext/date/lib/parse_date.lo ext/date/lib/parse_tz.lo ext/date/lib/timelib.lo ext/date/lib/tm2unixtime.lo ext/date/lib/unixtime2tm.lo ext/date/lib/parse_iso_intervals.lo ext/date/lib/interval.lo ext/ereg/ereg.lo ext/ereg/regex/regcomp.lo ext/ereg/regex/regexec.lo ext/ereg/regex/regerror.lo ext/ereg/regex/regfree.lo ext/libxml/libxml.lo ext/pcre/pcrelib/pcre_chartables.lo ext/pcre/pcrelib/pcre_ucd.lo ext/pcre/pcrelib/pcre_compile.lo ext/pcre/pcrelib/pcre_config.lo ext/pcre/pcrelib/pcre_exec.lo ext/pcre/pcrelib/pcre_fullinfo.lo ext/pcre/pcrelib/pcre_get.lo ext/pcre/pcrelib/pcre_globals.lo ext/pcre/pcrelib/pcre_maketables.lo ext/pcre/pcrelib/pcre_newline.lo ext/pcre/pcrelib/pcre_ord2utf8.lo ext/pcre/pcrelib/pcre_refcount.lo ext/pcre/pcrelib/pcre_study.lo ext/pcre/pcrelib/pcre_tables.lo ext/pcre/pcrelib/pcre_valid_utf8.lo ext/pcre/pcrelib/pcre_version.lo ext/pcre/pcrelib/pcre_xclass.lo ext/pcre/php_pcre.lo ext/sqlite3/sqlite3.lo ext/sqlite3/libsqlite/sqlite3.lo ext/zlib/zlib.lo ext/zlib/zlib_fopen_wrapper.lo ext/zlib/zlib_filter.lo ext/bcmath/bcmath.lo ext/bcmath/libbcmath/src/add.lo ext/bcmath/libbcmath/src/div.lo ext/bcmath/libbcmath/src/init.lo ext/bcmath/libbcmath/src/neg.lo ext/bcmath/libbcmath/src/outofmem.lo ext/bcmath/libbcmath/src/raisemod.lo ext/bcmath/libbcmath/src/rt.lo ext/bcmath/libbcmath/src/sub.lo ext/bcmath/libbcmath/src/compare.lo ext/bcmath/libbcmath/src/divmod.lo ext/bcmath/libbcmath/src/int2num.lo ext/bcmath/libbcmath/src/num2long.lo ext/bcmath/libbcmath/src/output.lo ex
Bug #61025 [Com]: __invoke() visibility not honored
Edit report at https://bugs.php.net/bug.php?id=61025&edit=1 ID: 61025 Comment by: re...@php.net Reported by:jpa...@php.net Summary:__invoke() visibility not honored Status: Open Type: Bug Package:Class/Object related Operating System: *nix PHP Version:5.3.10 Block user comment: N Private report: N New Comment: Hi, I made a patch again 5.5. how about fix it in 5.5? Previous Comments: [2012-07-30 02:22:11] willfi...@php.net johannes - I can commit a fix for this, but at what point should it be introduced? [2012-02-10 22:34:44] johan...@php.net Yes, the current behavior is wrong. I don't think it should be fixed in 5.3 though as the fix might break existing code. [2012-02-09 09:17:23] jpa...@php.net Description: __invoke() visibility is not honored when indirectly called as $obj(). It is, when directly called, via $obj->__invoke(); Please, note as well that declaring __invoke() as static works as well, I think it shouldn't (nonsense) Test script: --- __invoke(); */ Expected result: Call to private method Bar::__invoke() from context ... Actual result: -- Bar -- Edit this bug report at https://bugs.php.net/bug.php?id=61025&edit=1
Bug #53437 [PATCH]: Crash when using unserialized DatePeriod instance
Edit report at https://bugs.php.net/bug.php?id=53437&edit=1 ID: 53437 Patch added by: a...@php.net Reported by:from dot php dot net at brainbox dot cz Summary:Crash when using unserialized DatePeriod instance Status: Assigned Type: Bug Package:Date/time related Operating System: Windows XP SP3 PHP Version:5.3.3 Assigned To:derick Block user comment: N Private report: N New Comment: The following patch has been added/updated: Patch Name: glopes_date_5.3.patch Revision: 1362595811 URL: https://bugs.php.net/patch-display.php?bug=53437&patch=glopes_date_5.3.patch&revision=1362595811 Previous Comments: [2013-03-05 11:20:16] a...@php.net The following patch has been added/updated: Patch Name: glopes_date_5.4.patch Revision: 1362482416 URL: https://bugs.php.net/patch-display.php?bug=53437&patch=glopes_date_5.4.patch&revision=1362482416 [2013-03-05 11:19:39] a...@php.net The following patch has been added/updated: Patch Name: glopes_date_5.3.patch Revision: 1362482379 URL: https://bugs.php.net/patch-display.php?bug=53437&patch=glopes_date_5.3.patch&revision=1362482379 [2013-03-04 12:43:19] a...@php.net Here's the corresponding BT on windows, php5.dll!timelib_time_clone(timelib_time * orig) Line 52C php5.dll!date_period_it_rewind(_zend_object_iterator * iter) Line 1910C php5.dll!ZEND_FE_RESET_SPEC_CV_HANDLER(_zend_execute_data * execute_data) Line 22777C php5.dll!execute(_zend_op_array * op_array) Line 107C php5.dll!zend_execute_scripts(int type, _zval_struct * * retval, int file_count, ...) Line 1259C php5.dll!php_execute_script(_zend_file_handle * primary_file) Line 2316C php.exe!00b3246e()Unknown [Frames below may be incorrect and/or missing, no symbols loaded for php.exe] ntdll.dll!_RtlpHeapFindListLookupEntry@20 ()Unknown ntdll.dll!_RtlpFindEntry@8 ()Unknown 024d2608()Unknown msvcr90.dll!__getptd_noexit ()Unknown msvcr90.dll!__getptd ()Unknown msvcr90.dll!_LocaleUpdate::_LocaleUpdate(struct localeinfo_struct *)Unknown msvcr90.dll!__ismbcalpha ()Unknown msvcr90.dll!__ismbblead ()Unknown msvcr90.dll!__lock ()Unknown msvcr90.dll!__setargv ()Unknown msvcr90.dll!___getmainargs ()Unknown php.exe!00b32ca6()Unknown php.exe!00b32dca()Unknown kernel32.dll!@BaseThreadInitThunk@12 ()Unknown ntdll.dll!___RtlUserThreadStart@8 ()Unknown ntdll.dll!__RtlUserThreadStart@8 ()Unknown [2011-12-21 15:10:35] tony2...@php.net <@Cataphrac> (the Date(Period|Interval) serialization patch is here btw: http://nebm.ist.utl.pt/~glopes/misc/date_period_interval_ser.diff ) [2011-12-06 06:07:24] der...@php.net Automatic comment from SVN on behalf of derick Revision: http://svn.php.net/viewvc/?view=revision&revision=320479 Log: - Added a test case for #53437. 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=53437 -- Edit this bug report at https://bugs.php.net/bug.php?id=53437&edit=1
Bug #60723 [Com]: error_log error time has changed to UTC ignoring default timezo
Edit report at https://bugs.php.net/bug.php?id=60723&edit=1 ID: 60723 Comment by: pixelchutes at gmail dot com Reported by:olemarkus at gentoo dot org Summary:error_log error time has changed to UTC ignoring default timezo Status: Closed Type: Bug Package:Date/time related Operating System: Gentoo Linux PHP Version:5.3.9 Assigned To:derick Block user comment: N Private report: N New Comment: I can confirm this has indeed been patched (Confirmed for v5.3.22) BEFORE: [04-Mar-2013 00:39:07 UTC] PHP Warning: AFTER: [06-Mar-2013 06:27:16 America/Denver] PHP Warning: Previous Comments: [2013-02-25 11:14:51] martin dot marques at gmail dot com Don't see the fix in Debians testing packages (specifically 5.4.4), still seeing the UTC time instead of the local time: # apt-cache policy php5 php5: Instalados: 5.4.4-13 Candidato: 5.4.4-13 Tabla de versión: 5.5.0~alpha4-1 0 40 http://ftp.de.debian.org/debian/ experimental/main i386 Packages *** 5.4.4-13 0 500 http://ftp.de.debian.org/debian/ testing/main i386 Packages 50 http://ftp.de.debian.org/debian/ unstable/main i386 Packages 100 /var/lib/dpkg/status 5.3.3-7+squeeze14 0 500 http://security.debian.org/ squeeze/updates/main i386 Packages 500 http://ftp.de.debian.org/debian/ stable/main i386 Packages >From the log file: [25-Feb-2013 11:05:46 UTC] PHP Deprecated: Assigning the return value of new by reference is deprecated in /usr/share/php/MDB2.php on line 390 [2013-01-28 15:24:11] spam2 at rhsoft dot net i do not see anything fixed errorlog still contains the timezone PHP 5.3.21 as also 5.4.11 [28-Jan-2013 16:22:38 Europe/Vienna] PHP Parse error: syntax error, unexpected end of file in Command line code on line 1 the sysadmin knows his timezone well enough... [2012-10-10 21:19:40] pixelchutes at gmail dot com Should hopefully be released in 5.3.18, since 5.3.17 was released just a few days before the patch was committed (13-Sep-2012 vs 23-Sep-2012). Glad to hear this has been resolved, thanks! [2012-09-24 03:04:55] larue...@php.net hey, committed to 5.3 5.4 branches, will fixed in next release, thanks [2012-09-24 03:01:30] larue...@php.net Automatic comment on behalf of laruence Revision: http://git.php.net/?p=php-src.git;a=commit;h=923511d364ad84500bb097aca15385129ce6e336 Log: Fixed bug #60723 (error_log error time has changed to UTC ignoring default timezo) 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=60723 -- Edit this bug report at https://bugs.php.net/bug.php?id=60723&edit=1
Bug #41491 [Com]: header() adds extra x'200A' space/LF to start of file
Edit report at https://bugs.php.net/bug.php?id=41491&edit=1
ID: 41491
Comment by: dosergio at ig dot com dot br
Reported by:jeff at pointhere dot net
Summary:header() adds extra x'200A' space/LF to start of
file
Status: Not a bug
Type: Bug
Package:HTTP related
Operating System: Sun OS 5.10 (Solaris 10)
PHP Version:5.2.2
Block user comment: N
Private report: N
New Comment:
I have a similar problem.
If I use:
header("Content-type: application/json");
to a page that will serve actual json code, the response gains 4 spaces (char
32) at the beginning. Ok, this do not break the script, json still works but I
am questioning the fidelity of content, as those 4 spaces do not exist in
original json code but appears in the output when I set the header.
If I comment header line, the spaces disappear immediatelly. Already tried to
replace quotes by apostrofes (') but don't work either.
I suspect that header function is adding space internally.
Previous Comments:
[2007-05-28 20:10:13] tony2...@php.net
.
[2007-05-27 22:18:09] jeff at pointhere dot net
THAT DID IT!! I then started experimenting with the code - I took out all of
the code that had any variables and it worked. As soon as I added them in it
did not. Then I changed the code to work with apostrophes rather than quotes
and put the variables back in with a concatonation and it worked! I hope this
makes sense and leads to a fix using the quotes and replacable variables. This
code works as expected and you can color me thrilled:
// Start sending the file
ob_start();
header('Pragma: public');
header('Expires: 0');
header('Cache-Control: must-revalidate, post-check=0, pre-check=0');
header('Content-Type: text/plain');
header('Content-Disposition: attachment; filename="'.$filename.'"');
header('Content-Transfer-Encoding: 7bit');
echo($cardprint_file);
ob_end_flush();
Thank you so much for pointing me down the path that led me to a work-around
and a working program!!!
Jeff
[2007-05-27 17:50:20] il...@php.net
Can you try leaving header() calls with static parameters (no embeded
variables) and see if you still get the extra chars?
[2007-05-24 15:50:34] jeff at pointhere dot net
Description:
When using the header() function to prepend a text file so that a user can save
a downloaded file, the resulting file has two extra characters on the front of
the file (hex '200A' - space and line-feed). When header() functions are
removed, the file appears to load into the browser correctly.
Reproduce code:
---
// Start sending the file
ob_start();
header("Pragma: public");
header("Expires: 0");
header("Cache-Control: must-revalidate, post-check=0, pre-check=0");
header("Cache-Control: private", false);
header("Content-Type: text/plain");
header("Content-Length: " . $filesize);
header("Content-Disposition: attachment; filename=\"" . $filename . "\"");
header("Content-Transfer-Encoding: 7bit");
echo($cardprint_file);
ob_end_flush();
exit;
Expected result:
The user's browser should open a window that asks to Open, Save or Cancel the
download. When saving or opening the file the contents of $cardprint_file
should be the ONLY contents (the contents were verified to be correct with the
var_dump command).
Actual result:
--
The first two characters in the file (which translate to a blank line) are an
ASCII hex 20 (space) and an ASCII hex 0A (Line feed).
--
Edit this bug report at https://bugs.php.net/bug.php?id=41491&edit=1
Bug #45477 [Com]: ldap_mod_del() fails to remove attribute
Edit report at https://bugs.php.net/bug.php?id=45477&edit=1 ID: 45477 Comment by: asa_martin at hotmail dot com Reported by:alexis dot robert at gmail dot com Summary:ldap_mod_del() fails to remove attribute Status: No Feedback Type: Bug Package:LDAP related Operating System: * PHP Version:5.2.6 Block user comment: N Private report: N New Comment: The problem with ldap_mod_replace is that it performs a single replace operation. In Active Directory a single replace operation is the equivalent to resetting the password. To change a password one must delete and add. By default users have permission to change their own password but not to reset their own password. >From msdn http://msdn.microsoft.com/en-us/library/cc223248.aspx When a DC receives an LDAP Modify request to modify this attribute, it follows the following procedure: If the Modify request contains a delete operation containing a value Vdel for unicodePwd followed by an add operation containing a value Vadd for unicodePwd, the server considers the request to be a request to change the password. The server decodes Vadd and Vdel using the password decoding procedure documented later in this section. Vdel is the old password, while Vadd is the new password. If the Modify request contains a single replace operation containing a value Vrep for unicodePwd, the server considers the request to be a administrative reset of the password, that is, a password modification without knowledge of the old password. The server decodes Vrep using the password decoding procedure documented later in this section and uses it as the new password. Previous Comments: [2013-02-18 00:33:55] php-bugs at lists dot php dot net No feedback was provided. The bug is being suspended because we assume that you are no longer experiencing the problem. If this is not the case and you are able to provide the information that was requested earlier, please do so and change the status of the bug back to "Open". Thank you. [2010-05-21 12:11:05] m...@php.net What's wrong with http://php.net/ldap_mod_replace ? [2010-04-25 15:58:25] alexis dot robert at gmail dot com Is it solved in the main tree ? Else, can somebody can review my patch and tell me how it is ? I know it's a bit old (and maybe it needs a resync) but I had a lot of work to do this past two years for my classes. Thanks in advance :) Alexis [2008-08-19 11:51:34] alexis dot robert at gmail dot com I've done a patch which fixes the bug. It creates a ldap_mod_deleteadd function which delete an attribute and adding it in the same LDAP request. Some parts of the code is imported from pam_ldap. This bug also appears with MS Active Directory (when you bind without admin rights). The syntax is pretty obvious (but not very clean asap, i wanted to know if you like it before making it as pretty as ldap_mod_replace) : ldap_mod_deleteadd(resource link, string dn, string attr, string old, string new[, boolean binary = false]) The boolean binary attribute is here for AD which uses an unicode encoded password (and so needs LDAP_MOD_BVALUES). Currently waiting for your insults :) Alexis (The patch is at : http://alexis.robertlan.eu.org/tmp/001-ldap_php-add-mod_deleteadd.diff - created by cvs diff) [2008-07-18 11:56:50] alexis dot robert at gmail dot com OK. I've done a *lot* of researchs (trying to make TLS/SSL work, and some other fun things -- I hate certificates) and I discovered by analysing with tcpdump/wireshark that the current Java program make the delete+add orders in the same request, when my PHP software makes it in two different requests. So, NDS refuses to let the users have no userPassword attribute for a short period of time : that is the reason of the "Server unwilling to perform". As I don't think we can queue the requests in a FIFO-like stack in php_ldap's API, is it possible to send a LDIF using php_ldap ? That sounds to be a great solution. Thanks a lot Alexis 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=45477 -- Edit this bug report at https://bugs.php.net/bug.php?id=45477&edit=1
Bug #63894 [NoF]: Outdated copyright notice in snaps.php.net footer
Edit report at https://bugs.php.net/bug.php?id=63894&edit=1 ID: 63894 Updated by: m...@php.net Reported by:josh at trash-mail dot com -Summary:incorrect CURLINFO_HEADER_SIZE for proxied connections +Summary:Outdated copyright notice in snaps.php.net footer Status: No Feedback Type: Bug Package:cURL related -Operating System: +Operating System: irrelevant -PHP Version:5.4.10 +PHP Version:Irrelevant -Assigned To:pierrick +Assigned To:mj Block user comment: N Private report: N New Comment: The LICENSE file has been updated as well. Thanks for your report. Previous Comments: [2013-02-18 00:36:11] php-bugs at lists dot php dot net No feedback was provided. The bug is being suspended because we assume that you are no longer experiencing the problem. If this is not the case and you are able to provide the information that was requested earlier, please do so and change the status of the bug back to "Open". Thank you. [2013-01-04 07:15:43] pierr...@php.net Thank you for this bug report. To properly diagnose the problem, we need a short but complete example script to be able to reproduce this bug ourselves. A proper reproducing script starts with , is max. 10-20 lines long and does not require any external resources such as databases, etc. If the script requires a database to demonstrate the issue, please make sure it creates all necessary tables, stored procedures etc. Please avoid embedding huge scripts into the report. [2013-01-03 16:18:16] josh at trash-mail dot com Description: When using CURLOPT_PROXY to connect to an HTTPS resource via an HTTP debugging proxy (like charles) CURLINFO_HEADER_SIZE incorrectly reports the header size without any headers that the proxy might have added. Example #1 (without proxy) reports CURLINFO_HEADER_SIZE 198 (correct): ## HTTP/1.1 200 OK Content-Type: text/html; charset=UTF-8 Date: Thu, 03 Jan 2013 15:54:35 GMT Server: Apache/2.2.22 (Amazon) X-Powered-By: PHP/5.3.19 Content-Length: 15 Connection: Keep-alive ## Example #2 (via proxy) reports CURLINFO_HEADER_SIZE 198 (wrong): ## HTTP/1.0 200 Connection established HTTP/1.1 200 OK Content-Type: text/html; charset=UTF-8 Date: Thu, 03 Jan 2013 15:54:35 GMT Server: Apache/2.2.22 (Amazon) X-Powered-By: PHP/5.3.19 Content-Length: 15 Connection: Keep-alive ## Expected result: CURLINFO_HEADER_SIZE should always return the correct size - also when CURLOPT_PROXY is used with an HTTP proxy to connect an HTTPS resource. Actual result: -- CURLINFO_HEADER_SIZE returns the wrong size (without counting the additional headers from the proxy). -- Edit this bug report at https://bugs.php.net/bug.php?id=63894&edit=1
Bug #63894 [NoF]: incorrect CURLINFO_HEADER_SIZE for proxied connections
Edit report at https://bugs.php.net/bug.php?id=63894&edit=1 ID: 63894 Updated by: m...@php.net Reported by:josh at trash-mail dot com -Summary:Outdated copyright notice in snaps.php.net footer +Summary:incorrect CURLINFO_HEADER_SIZE for proxied connections Status: No Feedback Type: Bug Package:cURL related Operating System: irrelevant -PHP Version:Irrelevant +PHP Version:5.4.10 Assigned To:mj Block user comment: N Private report: N New Comment: Sorry for the mess. Previous Comments: [2013-03-06 20:34:56] m...@php.net The LICENSE file has been updated as well. Thanks for your report. [2013-02-18 00:36:11] php-bugs at lists dot php dot net No feedback was provided. The bug is being suspended because we assume that you are no longer experiencing the problem. If this is not the case and you are able to provide the information that was requested earlier, please do so and change the status of the bug back to "Open". Thank you. [2013-01-04 07:15:43] pierr...@php.net Thank you for this bug report. To properly diagnose the problem, we need a short but complete example script to be able to reproduce this bug ourselves. A proper reproducing script starts with , is max. 10-20 lines long and does not require any external resources such as databases, etc. If the script requires a database to demonstrate the issue, please make sure it creates all necessary tables, stored procedures etc. Please avoid embedding huge scripts into the report. [2013-01-03 16:18:16] josh at trash-mail dot com Description: When using CURLOPT_PROXY to connect to an HTTPS resource via an HTTP debugging proxy (like charles) CURLINFO_HEADER_SIZE incorrectly reports the header size without any headers that the proxy might have added. Example #1 (without proxy) reports CURLINFO_HEADER_SIZE 198 (correct): ## HTTP/1.1 200 OK Content-Type: text/html; charset=UTF-8 Date: Thu, 03 Jan 2013 15:54:35 GMT Server: Apache/2.2.22 (Amazon) X-Powered-By: PHP/5.3.19 Content-Length: 15 Connection: Keep-alive ## Example #2 (via proxy) reports CURLINFO_HEADER_SIZE 198 (wrong): ## HTTP/1.0 200 Connection established HTTP/1.1 200 OK Content-Type: text/html; charset=UTF-8 Date: Thu, 03 Jan 2013 15:54:35 GMT Server: Apache/2.2.22 (Amazon) X-Powered-By: PHP/5.3.19 Content-Length: 15 Connection: Keep-alive ## Expected result: CURLINFO_HEADER_SIZE should always return the correct size - also when CURLOPT_PROXY is used with an HTTP proxy to connect an HTTPS resource. Actual result: -- CURLINFO_HEADER_SIZE returns the wrong size (without counting the additional headers from the proxy). -- Edit this bug report at https://bugs.php.net/bug.php?id=63894&edit=1
Bug #63894 [NoF->Csd]: incorrect CURLINFO_HEADER_SIZE for proxied connections
Edit report at https://bugs.php.net/bug.php?id=63894&edit=1 ID: 63894 Updated by: m...@php.net Reported by:josh at trash-mail dot com Summary:incorrect CURLINFO_HEADER_SIZE for proxied connections -Status: No Feedback +Status: Closed Type: Bug Package:cURL related Operating System: irrelevant PHP Version:5.4.10 Assigned To:mj Block user comment: N Private report: N New Comment: This issue actually stems from a bug in libcurl. I have submitted a pull request for a change to upstream at https://github.com/bagder/curl/pull/60/commits. There is really not much that can be done within PHP because we are essentially only passing data back and forth between user-land and cURL. Folks affected by this simply need to wait for libcurl to be fixed. Previous Comments: [2013-03-06 20:37:20] m...@php.net Sorry for the mess. [2013-03-06 20:34:56] m...@php.net The LICENSE file has been updated as well. Thanks for your report. [2013-02-18 00:36:11] php-bugs at lists dot php dot net No feedback was provided. The bug is being suspended because we assume that you are no longer experiencing the problem. If this is not the case and you are able to provide the information that was requested earlier, please do so and change the status of the bug back to "Open". Thank you. [2013-01-04 07:15:43] pierr...@php.net Thank you for this bug report. To properly diagnose the problem, we need a short but complete example script to be able to reproduce this bug ourselves. A proper reproducing script starts with , is max. 10-20 lines long and does not require any external resources such as databases, etc. If the script requires a database to demonstrate the issue, please make sure it creates all necessary tables, stored procedures etc. Please avoid embedding huge scripts into the report. [2013-01-03 16:18:16] josh at trash-mail dot com Description: When using CURLOPT_PROXY to connect to an HTTPS resource via an HTTP debugging proxy (like charles) CURLINFO_HEADER_SIZE incorrectly reports the header size without any headers that the proxy might have added. Example #1 (without proxy) reports CURLINFO_HEADER_SIZE 198 (correct): ## HTTP/1.1 200 OK Content-Type: text/html; charset=UTF-8 Date: Thu, 03 Jan 2013 15:54:35 GMT Server: Apache/2.2.22 (Amazon) X-Powered-By: PHP/5.3.19 Content-Length: 15 Connection: Keep-alive ## Example #2 (via proxy) reports CURLINFO_HEADER_SIZE 198 (wrong): ## HTTP/1.0 200 Connection established HTTP/1.1 200 OK Content-Type: text/html; charset=UTF-8 Date: Thu, 03 Jan 2013 15:54:35 GMT Server: Apache/2.2.22 (Amazon) X-Powered-By: PHP/5.3.19 Content-Length: 15 Connection: Keep-alive ## Expected result: CURLINFO_HEADER_SIZE should always return the correct size - also when CURLOPT_PROXY is used with an HTTP proxy to connect an HTTPS resource. Actual result: -- CURLINFO_HEADER_SIZE returns the wrong size (without counting the additional headers from the proxy). -- Edit this bug report at https://bugs.php.net/bug.php?id=63894&edit=1
Bug #61025 [Opn]: __invoke() visibility not honored
Edit report at https://bugs.php.net/bug.php?id=61025&edit=1
ID: 61025
Updated by: larue...@php.net
Reported by:jpa...@php.net
Summary:__invoke() visibility not honored
Status: Open
Type: Bug
Package:Class/Object related
Operating System: *nix
PHP Version:5.3.10
Block user comment: N
Private report: N
New Comment:
I don't think this need to be fixed in this way, like __call:
```php
__call("name", NULL);
```
works well, but with an warning:
```
Warning: The magic method __call() must have public visibility and cannot be
static
```
I am not sure whether this is a bug, or just need document.
Previous Comments:
[2013-03-06 16:58:22] re...@php.net
Hi, I made a patch again 5.5. how about fix it in 5.5?
[2012-07-30 02:22:11] willfi...@php.net
johannes - I can commit a fix for this, but at what point should it be
introduced?
[2012-02-10 22:34:44] johan...@php.net
Yes, the current behavior is wrong. I don't think it should be fixed in 5.3
though as the fix might break existing code.
[2012-02-09 09:17:23] jpa...@php.net
Description:
__invoke() visibility is not honored when indirectly called as $obj().
It is, when directly called, via $obj->__invoke();
Please, note as well that declaring __invoke() as static works as well, I think
it shouldn't (nonsense)
Test script:
---
__invoke(); */
Expected result:
Call to private method Bar::__invoke() from context ...
Actual result:
--
Bar
--
Edit this bug report at https://bugs.php.net/bug.php?id=61025&edit=1
Bug #64370 [Opn->Asn]: microtime(true) corrupted
Edit report at https://bugs.php.net/bug.php?id=64370&edit=1 ID: 64370 Updated by: paj...@php.net Reported by:bugzilla77 at gmail dot com Summary:microtime(true) corrupted -Status: Open +Status: Assigned Type: Bug Package:Date/time related Operating System: win 7 (32/64) PHP Version:5.5.0alpha5 -Assigned To: +Assigned To:ab Block user comment: N Private report: N New Comment: @a can you take a look please? Previous Comments: [2013-03-06 15:45:36] bugzilla77 at gmail dot com Description: microtime(true) returns value less than time() (or $_SERVER['REQUEST_TIME'] or $_SERVER['REQUEST_TIME_FLOAT']) up to a DOZEN seconds!!! live demo: http://pulsmedica.com.pl/microtime.php win 7 32bit apache 2.4.3 + php5apache2_4.dll php 5.5a5 ts Test script: --- $_SERVER['REQUEST_TIME']: $_SERVER['REQUEST_TIME_FLOAT']: time(): microtime(true): PHP created in ms Expected result: PHP 5.4: never problems Actual result: -- PHP 5.5 live demo: http://pulsmedica.com.pl/microtime.php -- Edit this bug report at https://bugs.php.net/bug.php?id=64370&edit=1
Bug #64370 [Com]: microtime(true) corrupted
Edit report at https://bugs.php.net/bug.php?id=64370&edit=1 ID: 64370 Comment by: bugzilla77 at gmail dot com Reported by:bugzilla77 at gmail dot com Summary:microtime(true) corrupted Status: Assigned Type: Bug Package:Date/time related Operating System: win 7 (32/64) PHP Version:5.5.0alpha5 Assigned To:ab Block user comment: N Private report: N New Comment: The difference is not constant. It grows in proportion to the time since the last restart Apache. At the beginning it is a few milliseconds. After a few days up to several seconds. Previous Comments: [2013-03-07 06:56:22] paj...@php.net @a can you take a look please? [2013-03-06 15:45:36] bugzilla77 at gmail dot com Description: microtime(true) returns value less than time() (or $_SERVER['REQUEST_TIME'] or $_SERVER['REQUEST_TIME_FLOAT']) up to a DOZEN seconds!!! live demo: http://pulsmedica.com.pl/microtime.php win 7 32bit apache 2.4.3 + php5apache2_4.dll php 5.5a5 ts Test script: --- $_SERVER['REQUEST_TIME']: $_SERVER['REQUEST_TIME_FLOAT']: time(): microtime(true): PHP created in ms Expected result: PHP 5.4: never problems Actual result: -- PHP 5.5 live demo: http://pulsmedica.com.pl/microtime.php -- Edit this bug report at https://bugs.php.net/bug.php?id=64370&edit=1
