Ich habe gerade einen “doofen” Fehler im Backend von TYPO3 gefunden. Wahrscheinlich wird der TYPO3-Experte jetzt müde lächeln, aber wer noch nicht so viel Erfahrung mit TYPO3 hat wird zuerst auch komisch stutzen, warum denn die Datumseingabe nicht funktioniert.
Das Problem ist, dass ein Datum bei TYPO3 als Unix-Timestamp gespeichert wird und keine Werte <0 akzeptiert werden. Dies wird per JS gefiltert. Ich habe jetzt eine Lösung gefunden, wie man das JS anpassen kann. Sicherzustellen ist noch bei einer eigenen Extension, dass es ein signed int ist, dann steht dem Eingeben von Datums ab 1902 nichts mehr im Wege.
Das schöbne ist, dass es sich nicht um ein TYPO3-spezifisches Problem handelt, sondern um eine Erblast aus den Anfangszeiten von UNIX.
Freuen wir uns also schon mal auf den 19. Januar 2038, dann wird es noch einmal ähnlich spannend, wie zum Jahrtausendwechsel, da an diesem Termin der 32-bit UNIX-Timestamp überläuft
Ich glaub, bis 2038 wird es aber dann kaum mehr die alten unixe geben, und auch das php sollte dann soweit sein, eine fixkommazahl zu verwenden für das datum.
Es ist und bleibt aber ärgerlich, dass vor 1902 kein datum eingegeben werden kann. Ich hatte da mal einen Anwendungsfall (Newsapplikation aus der Sicht des 18. Jhdts.).
Nett find ich jedenfalls den Backlink!
Der Link zur Lösung hat sich geändert, sorry für die Umstände:
Hier der neue Link:
http://www.pakfeifer-riccabona.com/webdesign/linux-und-typo3-enterprise-cms/typo3-extensions/date-time-problem.html
Ich habe mich über diese UNIX Zahlen auch schon sehr geärgert. In Java wird wenigstens long für das Datum genutzt.
Wollte Geburtsdaten speichern (brummel) und so ganz darauf verlassen, dass niemand über 30 (bzw 100 bei signed int) sich eintragen will kann man ja auch nicht. Am Ende habe ich das Datum als String gespeichert.
Der Hinweis mit den UNIX Computern bis 2038 ist ja schön und gut aber es gibt immer genügend Bereiche, z.B. in medizinischen Geräten etc, vor allem im embeded Berreich prozessoren, die sehr lange halten sollen. Und auf vielen läuft UNIX. Es wird spannend werden. NUr wird wahrscheinlich niczt so eine öffentliche Hysterie wie bei dem Jahr 2000 Problem entstehen, da dieses PRoblem dem Laien viel schlechter zu präsentieren ist. Grade deswegen ist das Problem aber gefährlicher, denn es werden viel weniger Menschen darüber nachdenken ob durch das UNIX Datum mit älteren GEräten nun ein PRoblem entstehen könnte.
Liebe Grüße Lina
Linkänderung:
http://www.eur-ops.com/linux-und-typo3-enterprise-cms/typo3-extensions/date-time-problem.html
@lina: naja, das Problem liegt einfach im ganzzahligen Wert. Man sollte halt Datumsangaben nicht in ganzzahligen Werten speichern.
Ob das jetzt ein signed int ist, oder ein unsigned int oder ein long, irgendwann geht einem damit der Speicherplatz bei einem ganzzahligen Wert einfach aus - oder auch nicht.
Und genau da liegt dann der Hund begraben:
Ein long (oder auch big int) ist wieder in jeder Programmiersprache und auf jeder Plattform anders.
Man kann sich (wenn man für die nächsten 100 jahre programmieren will) auf so etwas also schlichterdings einfach nicht verlassen!
Was die medizinischen Geräte betrifft:
1. Wage ich zu bezweifeln, dass ein heute gekauftes medizinisches Gerät in 28 Jahren noch arg aktuell ist. Wenn man sich gerade die aufwändigeren Geräten heute (e.g. PET, CET, MRT u.ä.) anschaut, und dann 28 Jahre zurück geht, dann landet man quasi in der medizintechnischen Steinzeit.
2. Werden wohl vermutlich die embeded Codes der medizinischen Geräte nicht mit PHP+MySQL programmiert, vermutlich viel eher mit ANSI C/C++, in Zukunft möglicherweise sogar mit C#. Da schaut die Sache mit dem int schon wieder ganz anders aus, und mit dem datum sowieso, weil in ansi c/c++ nicht zwingendermaßen ein integer-wert für ein datum benutzt wird sondern ein eigener Datentyp time_t, der wiederum einen POSIX Zeitstempel implementiert (der auf einen long verweist). Durch die fortschreitende Umstellung auf 64bit Architekturen und einen 64bit time_t haben wir vermutlich schon lange vor 2038 alle wichtigen Systeme so weit, dass sie korrekt mit einem Zeitraum von 292 Milliarden Jahren umgehen können. Das sollte sogar für die Medizin reichen.
3. auf einem 64 bit system hat ein signed int folgende werte-grenzen: von −9.223.372.036.854.775.808 bis 9.223.372.036.854.775.807. auch damit dürfte man noch eine weile auskommen.
Viel spass beim nachrechnen
Fazit: Das Datumsproblem ist derzeit zwar ärgerlich aber zumindest teilweise lösbar, und vor dem Jahr 2038 brauchen wir auch keine Angst haben.