Dates cannot set before 1901-12-13 on 32bit

This was discussed at length in #2795489: 2038 bug with PHP timestamps on 32-bit systems - warn users?. If there is a workaround, then we can explore it.

+++ b/core/lib/Drupal/Component/Datetime/DateTimePlus.php
@@ -233,8 +233,13 @@ public static function createFromFormat($format, $time, $timezone = NULL, $setti
+      if ((float)$date->format("U") < -2147483648 || (float)$date->format("U") > 2147483647) {

Needs a comment on what is going on here and what those literals are.

Then, the `if (PHP_INT_SIZE)` checks in DateTimePlusTest should be removed and see if we have passing tests on 32-bit systems. We don't have any bots that support this, so it has to be verified manually.

I'll have a look at this as soon as possible, I have a couple of environments running in 32bits.

If anyone has time in the meanwhile docker32/php is a docker image running in 32bits. You can also specifying the PHP versions as different versions may or may not been affected in the same way (see this and following comments)

+++ b/core/lib/Drupal/Component/Datetime/DateTimePlus.php
@@ -233,8 +233,21 @@ public static function createFromFormat($format, $time, $timezone = NULL, $setti
+      if ((float)$date->format("U") < -2147483648 || (float)$date->format("U") > PHP_INT_MAX) {
+        //We deduct the amount of time since epoch so that the calculations for next line of code works
+        $bigDate = $date->format("U") - date("U");

Looks like we're adding 2-3 formats every creation? Can we just run it once?

Additionally hard coding "-2147483648" means it fails to act as expected on 64bit systems which is almost certainly the more common arch and the one this should be optimized for. Maybe we coud polyfill INT_MIN (as best we can) using INT_SIZE or something.

I think this issue can't be closed "won't fix" for the following reasons:
1) This is not a Drupal issue, not even PHP. It's deep in the 32bit architecture. Allowing Drupal to not fail won't fix the issue. It can actually even make it worse because we may let core correctly handle dates < 1901, but what about contrib modules? What about custom modules and custom code? or external libraries?
2) The tests is green because patch fixes the DateTimePlus implementation. But what about all the other strtotime() or getTimeStamp() calls? Are we going to fix those too? This problem has been raised in #2795489: 2038 bug with PHP timestamps on 32-bit systems - warn users? #17.
3) This is a int length problem in 32bits platforms. Those platforms have this limitation, which affects dates as well as math operations. That's a fact. If you are planning to have content handling dates < 1901 you are using the wrong platform as well as if you want to run a financial service. Fixing the Drupal side won't change the fact you do have a bigger issue.

We tell all of these with the alert message (we mention only the dates, but integers in general are affected).

I'll leave the decision to @mpdonadio and @jhedstrom as maintainers of the datetime modules and subsystems, and/or any framework manager.

I must mention I do understand Windows people may not have (yet) an alternative. But the effort on having all Drupal core and most of the modules - and some libraries - converted to allow dates < 1901 may be bigger then finding a solution to have 64bit PHP binary on Windows. :)

+++ b/core/tests/Drupal/Tests/Component/Datetime/DateTimePlusTest.php
@@ -307,18 +307,11 @@ public function providerTestDates() {
-      if (version_compare(PHP_VERSION, '5.6.15', '>=')) {
-        $dates[] = ['1809-02-12 10:30', 'America/Chicago', '1809-02-12T10:30:00-06:00'];
-      }

+++ b/core/tests/Drupal/Tests/Component/Datetime/DateTimePlusTest.php
@@ -343,18 +336,11 @@ public function providerTestDateArrays() {
-      if (version_compare(PHP_VERSION, '5.6.15', '>=')) {
-        $dates[] = [['year' => 1809, 'month' => 2, 'day' => 12], 'America/Chicago', '1809-02-12T00:00:00-06:00'];
-      }

These are invalid test changes. It will cause fails on a range of particular PHP, regardless of 32 vs 64 bit (see around #2795489-108: 2038 bug with PHP timestamps on 32-bit systems - warn users?). Needs work because of that.

In addition, the change is to ::createFromFormat, but the extreme dates don't go through that. I am a little baffled why we didn't add the dates to ::providerTestDateFormat(), too.

Taking this issue for a bit.

OK, here are test changes against 8.5.x

- removed the explicit 32-bit check
- added the extreme dates to the coverage for createFromFormat()
- added a new test to check the timestamp that comes back via createFromFormat(); https://3v4l.org/oh8mK make me confident this is correct

This comes up green for me locally in PHP7. Will trigger 5.5 and 5.6.

Can someone verify the fails, both test and input, on a 32-bit system and let us know what version of PHP exactly (the timezone database varies between versions and can impact some of the tests).

Assuming the bot likes this, any changes should make this version of DateTimePlusTest green, but I think we may need more timestamp testing.

I strongly believe that the ability to handle wider range of dates won't break any contrib modules.

I said the opposite: contrib modules may break websites. There are 43 calls to strtotime() in core only. I imagine the number of these calls in contrib and libraries is much more. By fixing DateTimePlus only we let the user believes he/she can use a wider range of dates, when this isn't totally true.

This isn't a hack

I have conflicting opinions about it. It is true Drupal and PHP on 32bit systems can both handle wider ranges of dates, as long as we avoid getting/setting timestamps. With the patch applied:

// Correct
$date = new DrupalDateTime('1890-05-05');
$date->format('Y-m-d H:i:s'); // 1890-05-05 00:00:00
$date->getTimestamp(); // -2513847600

// Fails
$date2 = strtotime('1890-05-05'); // FALSE

// Fails
$date3 = new DrupalDateTime();
$date3->setTimestamp($date->getTimestamp());
$date3->format('Y-m-d H:i:s'); // 2026-06-11 07:28:16
$date3->getTimestamp(); // 1781119696

// Fails
$date4 = DrupalDateTime::createFromTimestamp($date->getTimestamp());
$date4->format('Y-m-d H:i:s'); // 2026-06-11 07:28:16
$date4->getTimestamp(); // 1781119696

So if we continue with the work in here we have to fix the failing scenarios above, together with find a way to avoid developers to use strtotime() or any other code which can potentially break with dates out of 32bit timestamp allowance.

Not mentioning code standard, comment, polishing tweaks yet.

+++ b/core/lib/Drupal/Component/Datetime/DateTimePlus.php
@@ -233,8 +233,23 @@ public static function createFromFormat($format, $time, $timezone = NULL, $setti
+      if ((float)$date->format("U") < -2147483648 || (float)$date->format("U") > PHP_INT_MAX) {

Still need to add the 32-bit check to this.

+++ b/core/lib/Drupal/Component/Datetime/DateTimePlus.php
@@ -657,5 +672,9 @@ public function format($format, $settings = []) {
+  public function getTimestamp() {
+	return $this->format("U");
+  }

This needs a 32-bit check, too, to only use this method on 32-bit systems. It is also a BC break because \DateTime::getTimestamp() returns an int, while this will return a string, https://3v4l.org/T76Xv. This will cause problems where strict type checking is used.

Also need to merge in the test additions from #12 so we have a single patch. It is also helpful to post an interdiff with each new patch.

This is Needs Work for the reasons above. Leaving the Needs tests because we may need some more assertions.

Still pondering the comments from #13 on.

I appreciate your work and desire to figure out a solution here, but this issue is still Needs Work for the reasons in #16 (see issue status meanings). It will also require some nitpicks over coding standards at some point and probably a Change Record, but we are not at that point yet.

There can be no change to the way the class works on a 64-bit system including returned types; any potential changes need 32-bit checks in the code.

I am very worried about the impact of this change, especially considering our existing test coverage in this class, DrupalDateTime, the widgets, the formatters, and views, and the fact that we don't have 32-bit testbots to do full runs. The issue of BC is also a very serious consideration, as it is supposed to be maintained through minors, so Drupal 9 would be first place we can have one (except in extreme situations).

@ProFire thanks so much for your work on this issue!

It seems this is a duplicate of #2885413: Timestamp field items are affected by 2038 bug so I am going to close this to avoid having two streams of work dedicated to fix this. I would encourage you to check out the progress of that issue as it has had updates much more recently than this one.

I will also add you as a contributor to the issue so that you'll get credit if/when it gets fixed.

Thanks!