-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
Kleiner Nachtrag:
Mindestens PHP hat auch mit deutlich größeren Werten kein Problem.
> new \DateTime('@' . (pow(2, 38) - pow(2, 35)))
^^ Das gibt den 20.9.9592. Mein 64bit-PHP rechnet ganz offensichtlich
problemlos mit großen Zahlen.
> new \DateTime('@' . PHP_INT_MAX)
^^ Das ergibt den den 4.12.292277026596
Größere Zahlen (die PHP nicht mehr berechnen kann, die muss ich dann von Hand
in den "@\s+"-String schreiben) bleiben alle der 4.12.292277026596
... und damit kann PHP um den Faktor 50 weiter als bis zum Ende der Welt zählen.
Laut MySQL-Dokumentation ist da allerdings wirklich schon am 31.12.9999 Schluss.
Stephan Schuler
Web-Entwickler | netlogix Media
Telefon: +49 (911) 539909 - 0
E-Mail: stephan.schu...@netlogix.de
Web: media.netlogix.de
- -----Ursprüngliche Nachricht-----
Von: typo3-german-boun...@lists.typo3.org
[mailto:typo3-german-boun...@lists.typo3.org] Im Auftrag von Stephan Schuler
Gesendet: Mittwoch, 11. März 2015 17:42
An: Harald Stanzel; German TYPO3 Userlist
Betreff: Re: [TYPO3-german] wie handelt Extbase das Y2K38-Problem?
* PGP Signed: 03/11/2015 at 05:41:46 PM
Hallo Harald.
Die Frage klingt jetzt vielleicht blöd, aber hattest du nur den Datenbankanteil
umgestellt der auch dein TCA geändert?
http://docs.typo3.org/typo3cms/TCAReference/Reference/Columns/Common/Index.html#dbtype
Du solltest
* im TCA "eval" auf "date" stellen
* im TCA "dbType" auf "date"
* in der ext_tables.sql das Feld auf "date"
Das sollte dann eigentlich "rundum" dafür sorgen, dass kein signed int für das
Datum verwendet wird sondern
* PHP-Seitig im Backend ein String (was aber ohnehin der Fall ist) was das
TCEForms betrifft
* ein \Date-Objekt (oder \DateTime) was Extbasekomponenten betrifft
* und die native MySQL-Datumsdarstellung
Berechnungen sind da übrigens überhaupt nicht schwer, man kann problemlos
\DateInterval zwischen zwei \DateTime bilden und sich dann einen Integer der
Sekunden oder Jahre geben, je nach Geschmack. "Größer/kleiner"-Vergleiche gehen
mit \DateTime ebenfalls problemlos, genauso wie addieren oder subtrahieren.
Beides natürlich sowohl in PHP als auch in SQL.
Ich bin mir nur nicht so ganz sicher, ob TYPO3 da nicht irgendwo einen
unerwarteten Integer-Zwischenschritt einlegt der das Ganze dann doch wieder auf
MAXINT deckelt.
> new \DateTime('now + 1024 years')
^^ Das zumindest erzeugt bei mir ein DateTime-Objekt das auf den 11.3.3039
17:32:32 (Europe/Berlin) zeigt.
Das Jahr 5 Milliarden (Doctor Who, S1E02, The End of the World) lässt sich
leider nicht abbilden, zur Zeit ist beim 31.12.9999 Schluss. Das gilt sowohl
für meine Datenbank als auch für mein PHP. Die Datenbank formuliert das Datum
dann zu 0.0.0000 um, PHP wirft eine Exception.
Sollte TYPO3 bei der Datumsbehandlung mit den genannten Einstellungen "date"
für "eval", "dbType" und "ext_tables.sql" trotzdem ein Problem haben würde ich
das als Bug bezeichnen.
Nachvollzogen hab ich das allerdings noch nie, muss ich zugeben.
Gruß,
Stephan Schuler
Web-Entwickler | netlogix Media
Telefon: +49 (911) 539909 - 0
E-Mail: stephan.schu...@netlogix.de
Web: media.netlogix.de
netlogix GmbH & Co. KG
IT-Services | IT-Training | Media
Neuwieder Straße 10 | 90411 Nürnberg
Telefon: +49 (911) 539909 - 0 | Fax: +49 (911) 539909 - 99
E-Mail: i...@netlogix.de | Web: http://www.netlogix.de
netlogix GmbH & Co. KG ist eingetragen am Amtsgericht Nürnberg (HRA 13338)
Persönlich haftende Gesellschafterin: netlogix Verwaltungs GmbH (HRB 20634)
Umsatzsteuer-Identifikationsnummer: DE 233472254
Geschäftsführer: Stefan Buchta, Matthias Schmidt
- -----Ursprüngliche Nachricht-----
Von: typo3-german-boun...@lists.typo3.org
[mailto:typo3-german-boun...@lists.typo3.org] Im Auftrag von Harald Stanzel
Gesendet: Mittwoch, 11. März 2015 12:46
An: typo3-german@lists.typo3.org
Betreff: Re: [TYPO3-german] wie handelt Extbase das Y2K38-Problem?
Hmmm...
also das Format ist mir eigentlich relativ egal.
Was ich brauch, ist eine diskrete eindimensionale Abbildung der Zeit. Ich
brauch das nicht vierdimensional, ich brauch keine Zeit abhängig vom Ort. Für
meinen Geburtstag spielt es keine Rolle, ob ich in Los Angeles, in Peking oder
auf dem Mars geboren wurde. Die Uhrzeit würde ich - wenn überhaupt - als
schmückendes Beiwerk, wie den Geburtsort betrachten. Ich brauch eigentlich nur
"Date".
Ob mein Datum in der Form 1425992664 oder 2015-03-11 gespeichert wird, ist mir
so lang wie hoch.
Ich hab auch kein Problem, die Uhrzeit einfach zu ignorieren, wenn sie meint,
trotzdem dabei sein zu wollen.
Ich versuch, meine Probleme neu zu formulieren:
1. Der Wertebereich von 1901-2038 ist mir zu klein. Das trifft zu für +/- 2^31
... signed int(11)
2. Verwende ich andere Typen (mysql-seitig getestet, php-seitig den DateTime
belassen) tut gar nichts mehr. (*)
Und weiter:
Es erscheint mir logisch, daß es komplizierter wird, je mehr Technologien ich
verwende.
Deswegen hab ich es bisher so einfach wie möglich gehalten.
Ich verwende (noch) kein Javascript. Javascript kommt erst, wenn alles andere
tut.
> (*)"solltest du auf eine echte Datumsrepräsentation umsteigen (die
> Datenbanken haben einen eigenen Datentyp dafür!) kommen aber schnell
> andere Probleme auf"
..und zwar, daß dann gar nichts mehr tut. Die PHP-Seite weiß dann noch lange
nicht, wie sie korrekt mit Mysql kommunizieren soll.
Das Problem ist (laut meiner Erkenntnis), daß da immer ein timestamp erwartet
wird.
Ich habe Datetime ausprobiert. PHP-seitig ist das (z.B. "2015-03-11") aber dann
immer gleich null (=0 ="1.1.1970")
Je länger ich über dieses Problem grüble, umso vernünftiger scheint mir die
Realisierung als String. Ich dachte nur, das runde Rad sei schon erfunden und
ich müsste nicht mit meinem N-Eck fahren (bildlich gesprochen).
Gruß
Harald
_______________________________________________
TYPO3-german mailing list
TYPO3-german@lists.typo3.org
http://lists.typo3.org/cgi-bin/mailman/listinfo/typo3-german
* Stephan Schuler <stephan.schu...@netlogix.de>
* 0xC89B57C3(L)
_______________________________________________
TYPO3-german mailing list
TYPO3-german@lists.typo3.org
http://lists.typo3.org/cgi-bin/mailman/listinfo/typo3-german
-----BEGIN PGP SIGNATURE-----
Version: PGP Universal 3.3.2 (Build 15704)
Charset: utf-8
wpUDBQFVAHXppp0IwsibV8MBCBXmA/sFf57ZrDUwxzrbv8kN91I/RyEl3FgOtuT8
qco/m2ohbhuKDPj2fA64LQo0hFR1+DLJgt3eeOMfUALh4y0aPncpBZfM/h0vPeIo
uBXa+60TPXrRpi4ONOfPeQq5ktbyGdOXNXXRHxJjLc4AW3n2yRO/XsqvV7I5n7pr
gRaybeRC0Q==
=wa6j
-----END PGP SIGNATURE-----
_______________________________________________
TYPO3-german mailing list
TYPO3-german@lists.typo3.org
http://lists.typo3.org/cgi-bin/mailman/listinfo/typo3-german
