DateTime und Float Timestamps für 32-bit-Systeme

[jspit]

Der UNIX-Timestamp wird immer noch viel genutzt, getreu dem Motto 'Der Timestamp ist tot, es lebe der Timestamp'.
Auf Systemen mit 64-Bit-Integer hat der Timestamp auch kein Jahr 2038 Problem mehr und Zeiten vor 1970 werden als negative Timestamps abgebildet:

//Linux 64-Bit-INT
$date1 = date_create(null)->setTimestamp(10000000000);  //2286-11-20 18:46:40
$date2 = date_create(null)->setTimestamp(-10000000000); //1653-02-10 07:13:20 

Solche Timestamps werden so schnell nicht aussterben, wenn nicht sogar eine Renaissance erleben.
Werden obige Timestamps auf Systemen mit einem 32-Bit-Integer angeliefert, gibt es ein Problem,
denn obiger Code liefert dann ohne Warnung falsche Ergebnisse (s.Anmerkung):

//Win 32-Bit_INT
$date1 = date_create(null)->setTimestamp(10000000000);  //2014-09-07 06:50:08
$date2 = date_create(null)->setTimestamp(-10000000000); //1925-04-26 20:09:52 

Per modify-Methode kann jedoch auch auf 32-Bit-systemen ein Datumsobjekt aus einem Float-Timestamp erzeugt werden:

//Win 32-Bit-INT
$date1 = date_create(null)->setTimestamp(0)->modify(sprintf('%+.0f',10000000000).' Seconds');  
//2286-11-20 18:46:40
$date2 = date_create(null)->setTimestamp(0)->modify(sprintf('%+.0f',-10000000000).' Seconds');  
//1653-02-10 07:13:20 

Eine Möglichkeit der Umsetzung ist eine Klassenerweiterung von DateTime, welche die Methode setTimestamp() überschreibt:

  public function setTimestamp($unixtimestamp) {
    if(is_int($unixtimestamp)) {
      parent::setTimestamp($unixtimestamp);
    }
    elseif(is_float($unixtimestamp)) {
      parent::setTimestamp(0);
      $this->modify(sprintf('%+.0f',$unixtimestamp).' Seconds');
    }
  
    return $this;
  } 

Edit: Der obige Code zeigt ein möglichen Ansatz, ist jedoch noch nicht ausgetestet!

Kritik und Kommentare sind wie immer willkommen.

LG jspit

Anmerkung:
Die merkwürdigen Resultate beim Setzen des Timestamps auf 32-Bit-Systemen haben ihre Ursache im Verhalten von PHP beim Cast von Float auf Integer.

$floatVal = 10000000000.0;  //float(10000000000) 
$intVal = (int)$floatVal;   //int(1410065408) 

Ist der Floatwert grösser als PHP_INT_MAX, dann ist das Resultat nicht PHP_INT_MAX, sondern ein scheinbar beliebiger Integerwert,
der auch negativ sein kann:

var_dump( (int)12345678901 ); //int(-539222987) 

Dieses Verhalten ist nicht etwa ein Window-Bug, sondern auch auf Linuxsystemen mit 32-Bit-INT beobachtet worden (Alle?).

[tr0y]

Ein Bigint draft ist unterwegs, möglicherweise sind solche Workarrounds mit PHP 7 unnötig.

https://wiki.php.net/rfc/bigint