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

Wed Mar 11 18:05:43 CET 2015

-----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.Schuler at netlogix.de
Web: media.netlogix.de

- -----Ursprüngliche Nachricht-----
Von: typo3-german-bounces at lists.typo3.org [mailto:typo3-german-bounces at 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.Schuler at 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: info at 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-bounces at lists.typo3.org [mailto:typo3-german-bounces at lists.typo3.org] Im Auftrag von Harald Stanzel
Gesendet: Mittwoch, 11. März 2015 12:46
An: typo3-german at 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 at lists.typo3.org
http://lists.typo3.org/cgi-bin/mailman/listinfo/typo3-german

* Stephan Schuler <Stephan.Schuler at netlogix.de>
* 0xC89B57C3(L)
_______________________________________________
TYPO3-german mailing list
TYPO3-german at 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-----