* PHP-5.4:
Fixed bug #61611 ext\date\tests\date_default_timezone_get-2.phpt fails
Fixed bug #61631 mbstring mail related tests fail
Fixed bug #61610 Test ext\date\tests\date_default_timezone_get-1.diff fails
Fix bug #61609 Test ext\date\tests\bug52062.phpt fails As expressed in the comments http://de.php.net/manual/en/datetime.gettimestamp.php this is the generic 32 bit timestamp issue
Fixed bug #61631 mbstring mail related tests fail
Fixed bug #61610 Test ext\date\tests\date_default_timezone_get-1.diff fails
Fix bug #61609 Test ext\date\tests\bug52062.phpt fails As expressed in the comments http://de.php.net/manual/en/datetime.gettimestamp.php this is the generic 32 bit timestamp issue
MFH: fixed a mistake on reverting my previous patch.
* PHP-5.3:
Fixed bug #61611 ext\date\tests\date_default_timezone_get-2.phpt fails
Fixed bug #61631 mbstring mail related tests fail
Fixed bug #61610 Test ext\date\tests\date_default_timezone_get-1.diff fails
Fix bug #61609 Test ext\date\tests\bug52062.phpt fails As expressed in the comments http://de.php.net/manual/en/datetime.gettimestamp.php this is the generic 32 bit timestamp issue
The behaviour on windows is to select an arbitrary timezone from the
current system settings. This gives no chance to hardcode the timezone
name, for instance for UTC+1 it could choose from the multiple names
like Europe/Berlin or Europe/Paris . For this reason the test is
parametrized so there is no hardcoded timezone data.
The original test made to be skipped on windows and a duplicate was made
for windows. Tested on debian and win7 both x86.
The behaviour on windows is to select an arbitrary timezone from the current system settings.
This gives no chance to hardcode the timezone name, for instance for UTC+1 it could choose
from the multiple names like Europe/Berlin or Europe/Paris . For this reason the test is
parametrized so there is no hardcoded timezone data.
The original test made to be skipped on windows and a duplicate was made for windows.
The behaviour on windows is to select an arbitrary timezone from the current system settings.
This gives no chance to hardcode the timezone name, for instance for UTC+1 it could choose
from the multiple names like Europe/Berlin or Europe/Paris . For this reason the test is
parametrized so there is no hardcoded timezone data.
The original test made to be skipped on windows and a duplicate was made for windows.
The behaviour on windows is to select an arbitrary timezone from the current system settings.
This gives no chance to hardcode the timezone name, for instance for UTC+1 it could choose
from the multiple names like Europe/Berlin or Europe/Paris . For this reason the test is
parametrized so there is no hardcoded timezone data.
The original test made to be skipped on windows and a duplicate was made for windows.
Generate T_STRING_VARNAME only if it actually is one. This is only the case
for "${varname}" and "${varname[offset]}" so we can just add a check for
} or [ after the LABEL.
Headers: forbid \r and \n also after \0, allow CRLF followed by HT or SP and forbid \0. See bug #60227.
Conflicts:
ext/standard/tests/general_functions/bug60227.phpt
ext/standard/tests/general_functions/bug60227_1.phpt
ext/standard/tests/general_functions/bug60227_2.phpt
main/SAPI.c
