TYPO3 Core

please run this code on your machine:

<?php

function testInteger()
{
    return is_int(2247483648);
}

function buildDate()
{
    return new \DateTime('@' . 2247483648);
}

var_dump(testInteger());
var_dump(buildDate());

The result on my machine is:

/Volumes/Web/docRoot/typo3-core/Web/fileadmin/test.php:13:boolean true
/Volumes/Web/docRoot/typo3-core/Web/fileadmin/test.php:14:
object(DateTime)[1]
  public 'date' => string '2041-03-21 13:00:48.000000' (length=26)
  public 'timezone_type' => int 1
  public 'timezone' => string '+00:00' (length=6)

Hm, on 32-bit systems (32-bit PHP on 64-bit OS makes this 32-bit) you are bound to the int restrictions of 32-bit. With 32-bit you can't handle dates >year 2038 being represented by ints. So fluid would be able to cope with it but if you want to save those values in the database (assuming mysql running with 32-bit too) it will break again.

Another option I see is to adjust DateViewHelper:

  $base = $base instanceof \DateTimeInterface ? $base->format('U') : strtotime((MathUtility::canBeInterpretedAsInteger($base) ? '@' : '') . $base);
  $dateTimestamp = strtotime((MathUtility::canBeInterpretedAsInteger($date) ? '@' : '') . $date, $base);

Do not use MathUtility::canBeInterpretedAsInteger() (as apparently the number can be bigger as representable by int) but some other kind of check e.g. preg_match (slow) or is_numeric.

After some research I guess is_numeric is the way to go: According to http://php.net/manual/de/function.is-numeric.php#102011 is_numeric can handle very big numbers.

Could you please test this:

<?php

function testNumeric() {
    return is_numeric(2247483648);
}

function buildDate()
{
    return new \DateTime('@' . 2247483648);
}

var_dump(testNumeric());
var_dump(buildDate());

If that works

  $base = $base instanceof \DateTimeInterface ? $base->format('U') : strtotime((is_numeric($base) ? '@' : '') . $base);
  $dateTimestamp = strtotime((is_numeric($date) ? '@' : '') . $date, $base);

I suggest either closing this issue or turning it into a TASK to add a new report that warns about 32 bit systems, as suggested by Georg. I've taken the liberty of removing the Fluid category as this doesn't only pertain to Fluid - and assigning it to the Reports category.

Alternatively this may better belong in "core" if we need to somehow declare 64bit as hard requirement.

Hey all,

as this is a 32 bit issue (and apparantly most hosters with 32bit systems are currently migrating away to 64bit - same goes for Mac OS etc), this issue will be "fixed" on its own. I'm glad to have it this way, otherwise this would have meant that we would have to refactor most of TYPO3's Core APIs. This way, we're safe - if somebody needs these kind of things, one should upgrade to a 64 bit system.