Skip to main content, zum Hauptinhalt springen
 
 
 
 
 

Das TYPO3 Backend und das Datumsproblem

Wie inzwischen hinlänglich bekannt sein dürfte, lässt sich im TYPO3 Backend nicht so ohne weiteres ein Datum eingeben, das kleiner ist als der 01.01.1970, 00:00.

 

Warum: TYPO3 verwendet intern das Unix Timestamp Format. Im Unix Timestamp Format ist jedes Datum mit Uhrzeit mit einer Zahl vom Typ Integer repräsentierbar. Die Null (0) entspricht dabei genau dem 01.01.1970 00:00.

Gezählt wird dabei mit sogenannten "Ticks". Nein, das hat nichts mit dem Zucken eines Augenlides zu tun! Im Unix Timestamp System entspricht ein Tick genau einer Sekunde, unter .NET entspräche ein Tick beispielsweise 10 Nanosekunden. "Tick" soll also nur das kontinuierliche inkrementieren eines Zeitstroms lautmalerisch symbolisieren, ähnlich dem Ticken des Sekundenzeigers einer Uhr, unabhängig von der der 'Tick-Frequenz'.


Man sieht, es wird verwirrend! Dabei kommen wir jetzt erst zu den Datentypen! Gespeichert wird nämlich das Ganze in ein int(11), zumindest in TYPO3. Ein int(11) ist in der Lage einen Wert des Zahlenraums bis inklusive 11 Stellen zu speichern. Theoretisch wäre das also ein Wert von -99999999999 bis 99999999999. Praktisch hängt dies aber noch von mehreren anderen Faktoren ab. Auf einem 32 bit System entspricht ein int(11) normalerweise genau einer "möglichen Werte Menge" von 4.294.967.295 + 1.

Ja wieso denn "+1"?? -  Ganz einfach. Diese entspricht der Anzahl der möglichen Werte von 0 bis 4.294.967.295. Und das sind nun einmal einfach 4.294.967.296 mögliche annehmbare Werte.

 

Jetzt wird es noch komplizierter! Man unterscheidet nun in typsicheren (oder eigentlich in allen typisierten) Sprachen noch zwischen sogenannten 'signed' und 'unsigned' Datentypen. Signed heißt, daß der Wert vorzeichenbehaftet ist, also ob ein + oder ein - davor steht. Ein 32 bit signed int(11) kann gleichviele Werte annehmen, wie ein 32 bit unsigned int(11), es findet lediglich eine Verschiebung der "möglichen Werte Menge" statt. Diese Menge wäre dann von -2.147.483.648 bis +2.147.483.647. Das sind genau wieder 4.294.967.295 + 1 mögliche Werte (nicht die Null vergessen, ist ja auch ein Wert *g* ).

 

Was bedeutet das für TYPO3? - Gott sei Dank ist PHP 4.x nicht typsicher, ja eigentlich noch nicht einmal richtig typisiert. Daher ist in den meisten Fällen ein Rechnen mit negativen Integer Zahlen problemlos. ABER: PHP unter Windows ist leider nicht so geduldig, hier kann leider nicht mit negativen Unix Timestamps gerechnet werden. Zu PHP 5.x kann ich an dieser Stelle leider noch nichts sagen. Der Datentyp des Datenbankfelds ist zumindest unter MySQL 4.x auf einer Linux Plattform auch kein Thema. Zumindest solange es nicht explizit ein 'unsigned' ist!!

 

Alle anderen Probleme zum Thema Zeit möchte ich an dieser Stelle vernachlässigen (UTC, GMT, Schaltsekunden, EPOCH, etc...), da das diesen Artikel sprengen würde!

 

Daher kann man auf Linux Systemen folgende Änderungen vornehmen, um auch negative Timestamps speichern zu können:

 

// Changes in TYPO3 v. 4.0.2
// !!!!! Achtung: NICHT WINDOWS KOMPATIBEL !!!!! ATTENTION, NOT COMPATIBLE WITH WINDOWS


// t3lib/jsfunc.evalfield.js, line 349:
// Änderung ermöglicht Datumseingabe von 1902 ++


if (  (year >= 0 && year < 38) || (year >= 02 && year < 100) || (year >= 1902 && year < 2038)  )  {


// t3lib/jsfunc.evalfield.js, line 368:
// Diese Zeile einfach auskommentieren!

// if (this.lastDate < 0) {this.lastDate = 0;}


Eines sollte allerdings klar sein: Die Änderungen sollten nur von Leuten durchgeführt werden, die mit Datentypen und Timestamps auch was anfangen können und müssen hinterher auf jeden Fall ausgiebig getestet werden. Es kann sonst im schlimmsten Fall auch zu korrupten Datensätzen führen!!

 

 

 

Fazit

In den Versionen 4.x.x von TYPO3 wird sich bezüglich des Datums leider nichts mehr ändern. Die Änderungen wären wohl zu weitreichend und zu komplex, als daß dies der großen TYPO3 Community zugemutet werden könnte.

Ich hoffe aber, daß in TYPO3 NEOS die Chance ergriffen wird diese Unzulänglichkeit auszumerzen.

Ein möglicher Ansatz wäre, Datumsangaben in Zukunft in Gleitkommazahlen zu speichern. Dies ist mittlerweile durchaus üblich, und moderne Prozessorarchitekturen können Berechnungen dieser Art inzwischen genauso in einem Takt erledigen. Damit wäre man weiterhin Plattformunabhängig, aber weitaus flexibler was Datumsangaben betrifft, als mit allen andern Systemen.

Falls in PHP 5.x keine Funktion zur Verfügung steht, um Datumsangaben in Gleitkommazahlen zu konvertieren und umgekehrt, müsste TYPO3 NEOS eben eine derartige API Funktion mitbringen. Der schätzungsweise nicht einmal so große Aufwand wäre jedenfalls mehr als gerechtfertigt!

 

Anmerkung: Die Lösung wurde aus einigen Foren zusammengetragen, und an die aktuelle Version von t3 angepasst (Zeilennummern). In allen Foreneinträgen wird zumindest auf Bernhard Kraft verwiesen, wenn er nicht gar selbst gepostet hat. Daher sollte der Dank also mehr Herrn Kraft gebühren als uns! ;)

 

 

Und all jenen die noch nicht genug haben von Problemen mit Zeit und Zeitzonen in der Softwareentwicklung sei folgendes Youtube-Schmuckstück ans Herz gelegt!

 

 

 

 
 
 

Sehr geehrter Besucher! Leider verwenden Sie einen veralteten Browser. Sie können einen sehr guten, sicheren, stabilen und zeitgemässen Browser kostenlos unter dem folgenden Link herunterladen: Firefox Browser auf www.mozilla.org Dieser Browser ist erhältlich für: Windows, MacOS (Apple), iPhone, Android und Linux.