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
_______________________________________________
TYPO3-german mailing list
TYPO3-german@lists.typo3.org
http://lists.typo3.org/cgi-bin/mailman/listinfo/typo3-german
