Bug #75851 [Opn->Csd]: Year component overflow with date formats "c", "o", "r" and "y"

Edit report at https://bugs.php.net/bug.php?id=75851&edit=1 ID: 75851 Updated by: cmb@php.net Reported by: juju2143 at gmail dot com Summary: Year component overflow with date formats "c", "o", "r" and "y" -Status: Open +Status: Closed 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: Automatic comment on behalf of as Revision: http://git.php.net/?p=php-src.git;a=commit;h=c097acd52e89a3b1d0cb6a181bb4650be9625b6c Log: Fix #75851: Year component overflow with date formats "c", "o", "r" and "y" Previous Comments: ------------------------------------------------------------------------ [2018-01-20 23:21:25] daverandom@php.net I would imagine this has been present for a long time, as year component is cast down to system int type for formatting. It's stored internally in timelib as a timelib_sll, which is a 64-bit signed integer, so it should be safe (afaict) to cast it to a zend_long instead and format it with %lld. However, I'm not intimately familiar with PHP's internal printf augmentations, nor with timelib or ext/date, and I do not have a 32-bit system to test my changes against, which is why I would like it reviewed by someone who knows what they are doing before merging it :-) ------------------------------------------------------------------------ [2018-01-20 19:49:59] juju2143 at gmail dot com Thanks! Also note that I also reproduced it on 7.0.27 on Linux and might also work on 7.2. ------------------------------------------------------------------------ [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