[TYPO3-german] wie handelt Extbase das Y2K38-Problem?

[bernd wilke]

Am 10.03.15 um 19:06 schrieb Harald Stanzel:
> Hallo zurück,
>
> laut de2.php.net/manual/de/intro.datetime.php hat DateTime 64 Bit. Mir
> würden schon 32 reichen, wenn nicht über die Hälfte davon für die
> Sekunden eines einzigen Tages drauf gehen würden.
> Ich hab hier drei Dinge:
> PHP, Mysql und dazwischen Extbase. Wie ich bisher verstanden habe,
> kennen PHP und Mysql 64Bit lange Datetime.
>
> Problem 1: int(11) ist mit Sicherheit zu klein, Maximalwert 2^31 - den
> hat mir der Ext.Builder gemacht.
> Allein die Angabe von int(20), welcher dann +/- 2^63 könnte,
> funktioniert aber nicht.
> Denn der Wertebereich bleibt der selbe.
>
> Problem 2: Ändere ich diesen int(11) auf Date oder DateTime funktioniert
> gar nichts mehr (NULL-Value in beide Richtungen,d.h. phpmyadmin zeigt
> 0000-00-00 und mein FE zeigt 1.1.1970)
>
> Deswegen schlussfolgere ich, daß beim Property mappen oder sonstwo in
> den Untiefen von Extbase IMMER ein timestamp aus dem Datum generiert
> wird. Und bei diesem ist bekannt, daß am 19.1.2038 das Ende erreicht wird.
>
> Problem 3: Ich habe nicht die leiseste Ahnung, wo und nach was ich noch
> suchen sollte.
solange du bei der Repräsentation von Datumsangaben durch Integer als 
Unixtime (= Sekunden seit 1.1.1970 0:00:00) bleibst wirst du Probleme 
haben.
Probleme rund um diese Datumsrepräsentation:
1. Zeitzonen, da die Uhrzeit mit genutzt wird müssen Zeitzonen 
berücksichtigt werden. da man bei einem reinen Datum meist die Uhrzeit 
0:00 nimmt kann es bei einer Zeitzonen'korrektur' auf einmal zu 23:00 
des Vortages werden: Ohne angezeigte Uhrzeit auf einmal ein anderes Datum
2. es ist ja nicht nur PHP beteiligt. neben der Datenbank, die 
hoffentlich nur eine große Integer Zahl sieht gibt es ja auch noch 
Javascript, das zumindest bei der Eingabe noch beteiligt ist, sei es für 
einen Kalender-Wizard, sei es nur zur Wert-Überprüfung. D.h. aber auch 
Javascript von ganz unterschiedlichen Browsern, und da unterscheidet 
sich IE8 von IE11 und FF unter Windows von FF unter Linux

solltest du auf eine echte Datumsrepräsentation umsteigen (die 
Datenbanken haben einen eigenen Datentyp dafür!) kommen aber schnell 
andere Probleme auf:
Die Eingabe wird kompliziert weil man jetzt drei Felder zusammen 
validieren muss (oder ein Feld erstmal zerlegen und dann wieder 
kombinieren muss)
Berechnungen bzgl. Tagesdifferenz zwischen zwei Daten (pl. Datum) werden 
um einiges komplizierter.
Das ist in so weit für dich so aufwändig weil TYPO3 noch kein sauberes 
Interface für diesen DB-Datentyp hat.

andere Auswege: eine komplett eigene Datumsverwaltung mit einem 
Datentyp, der eigentlich ein String ist:
speichere ein Datum einfach als String "YYYY:MM:DD" mit einer einfachen 
Validierung und einfacher Anzeigeformatierung. Du kannst damit halt nur 
nicht viel 'rechnen'. (Bei dieser Formatierung funktioniert immerhin ein 
kleiner/größer Vergleich)

bernd
-- 
http://www.pi-phi.de/cheatsheet.html