Edit report at https://bugs.php.net/bug.php?id=75851&edit=1
ID: 75851
Comment by: juju2143 at gmail dot com
Reported by: juju2143 at gmail dot com
Summary: Year component overflow with date formats "c", "o",
"r" and "y"
Status: Open
Type: Bug
Package: Date/time related
Operating System: macOS 10.12
PHP Version: 7.1.13
Block user comment: N
Private report: N
New Comment:
Thanks! Also note that I also reproduced it on 7.0.27 on Linux and might also work on 7.2.
Previous Comments:
------------------------------------------------------------------------
[2018-01-20 11:42:22] daverandom@php.net
I have worked up a PR for this but I'm not going to merge it without review.
------------------------------------------------------------------------
[2018-01-20 09:46:01] juju2143 at gmail dot com
Changed the title.
------------------------------------------------------------------------
[2018-01-20 09:38:35] juju2143 at gmail dot com
Description:
------------
I'm not sure whether PHP or even the human species will still be around when someone would want
to process dates past the year 2147483647, but it seems that the format characters c, o, r, y
(actually, probably everything that calculates the year except Y, L is untested) as defined in the
date() manual page will compute the year component in a 32-bit integer. For consistency with Y, it
might be desirable to upgrade those to 64-bit on 64-bit systems as well.
Test script:
---------------
echo date(DATE_ATOM."\n".DATE_RFC2822."\nc\nr\no\ny\nY\nU\n\n", PHP_INT_MIN);
echo date(DATE_ATOM."\n".DATE_RFC2822."\nc\nr\no\ny\nY\nU\n\n",
67767976233532799);
echo date(DATE_ATOM."\n".DATE_RFC2822."\nc\nr\no\ny\nY\nU\n\n",
67767976233532800);
echo date(DATE_ATOM."\n".DATE_RFC2822."\nc\nr\no\ny\nY\nU\n\n", PHP_INT_MAX);
Expected result:
----------------
-292277022657-01-27T08:29:52+00:00
Fri, 27 Jan -292277022657 08:29:52 +0000
-292277022657-01-27T08:29:52+00:00
Fri, 27 Jan -292277022657 08:29:52 +0000
-292277022657
57 (or -57?)
-292277022657
-9223372036854775808
2147483647-12-31T23:59:59+00:00
Tue, 31 Dec 2147483647 23:59:59 +0000
2147483647-12-31T23:59:59+00:00
Tue, 31 Dec 2147483647 23:59:59 +0000
2147483648
47
2147483647
67767976233532799
2147483648-01-01T00:00:00+00:00
Wed, 01 Jan 2147483648 00:00:00 +0000
2147483648-01-01T00:00:00+00:00
Wed, 01 Jan 2147483648 00:00:00 +0000
2147483648
48
2147483648
67767976233532800
292277026596-12-04T15:30:07+00:00
Sun, 04 Dec 292277026596 15:30:07 +0000
292277026596-12-04T15:30:07+00:00
Sun, 04 Dec 292277026596 15:30:07 +0000
292277026596
96
292277026596
9223372036854775807
Actual result:
--------------
-292277022657-01-27T08:29:52+00:00
Fri, 27 Jan -292277022657 08:29:52 +0000
-219246529-01-27T08:29:52+00:00
Fri, 27 Jan -219246529 08:29:52 +0000
-219246529
-29
-292277022657
-9223372036854775808
2147483647-12-31T23:59:59+00:00
Tue, 31 Dec 2147483647 23:59:59 +0000
2147483647-12-31T23:59:59+00:00
Tue, 31 Dec 2147483647 23:59:59 +0000
-2147483648
47
2147483647
67767976233532799
2147483648-01-01T00:00:00+00:00
Wed, 01 Jan 2147483648 00:00:00 +0000
-2147483648-01-01T00:00:00+00:00
Wed, 01 Jan -2147483648 00:00:00 +0000
-2147483648
-48
2147483648
67767976233532800
292277026596-12-04T15:30:07+00:00
Sun, 04 Dec 292277026596 15:30:07 +0000
219250468-12-04T15:30:07+00:00
Sun, 04 Dec 219250468 15:30:07 +0000
219250468
68
292277026596
9223372036854775807
------------------------------------------------------------------------
--
Edit this bug report at https://bugs.php.net/bug.php?id=75851&edit=1