This fixes the issue in
https://wiki.php.net/rfc/datetime_and_daylight_saving_time#forward_transitions
There is a period during transition to DST where a time (such as 02:30) does
not exist. PHP already calculated the correct timestamp for this, but failed to
"rounded forward" to the existing correct hour value.
* 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.
Anatol Belski