go to bug id or search bugs for
The result of IntlDateFormatter::parse is integer and is limited to the integer range. (i.e. IntlDateFormatter::parse returns The least integer value (e.g. -2147483648 in 32-bit Platforms) when the result is out of the integer range.)
$fmt = new IntlDateFormatter("en_US", IntlDateFormatter::FULL, IntlDateFormatter::FULL);
var_dump($fmt->parse("Wednesday, January 20, 2038 3:14:07 AM GMT"));
Add a Patch
Add a Pull Request
Out of curiosity - how do you expect to use past-2038 timestamps? Many Unix systems won't support those. Do you expect 64-bit value or some other way? float might be not very good for it due to the precision loss.
Actually what I want to do is to convert dates between different calendars and to do so I'm using the returned timestamp with IntlDateFormatter::format method as follow:
$df_persian = new IntlDateFormatter('en@calendar=persian', IntlDateFormatter::FULL, IntlDateFormatter::FULL, 'Asia/Tehran', IntlDateFormatter::GREGORIAN, 'yyyy-MM-dd');
$df_gregorian = new IntlDateFormatter('en', IntlDateFormatter::FULL, IntlDateFormatter::FULL, 'Asia/Tehran', IntlDateFormatter::GREGORIAN, 'yyyy-MM-dd');
Hopefully, format method accepts float values as argument and the only problem is parse method which doesn't return past-2038 timestamps.
And by the way float precision loss wouldn't be a problem at least for timestamps up to 14 decimal digits.
Automatic comment from SVN on behalf of stas
Log: Fix bug #50590 - IntlDateFormatter::parse result is limited to the integer range
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
Thank you for the report, and for helping us make PHP better.
Automatic comment from SVN on behalf of cataphract
Log: - Fixed test for bug #50590 on systems with 64-bit longs.