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

[Harald Stanzel]

Hallo wertes Forum und Mitglieder,

ich habe mit dem ExtensionBuilder eine kleine Extension gekickstartet, in der Personendaten und Familienverhältnisse abgespeichert werden mit dem Ziel Stammbäume darzustellen.
Eine Person hat außer Vor-, Zu- und sonstige Namen noch einen Geburtstag und (eventuell, früher oder später) einen Todestag.

Im Ext.Builder habe ich dafür "Date" gewählt. Im Model erhalte ich damit DateTime und die entsprechende DB-Spalte wird zu
int(11) DEFAULT '0' NOT NULL
Das funktioniert auch soweit - solange ich im Bereich 1901-2038 bleibe.
Gebe ich im FE ein Datum drüber oder drunter ein, wird das Maximum, bzw. Minimum abgespeichert.

Nun möchte ich gern wissen, ob und wie Extbase mit Datumsangaben vor 1901 / nach 2038 umgeht oder wie ich das deichseln kann, damit es tut.
Leider hat meine bisherige Suche nur ergeben, daß das Problem mehr oder weniger bekannt ist. (Nochmal) leider hab ich bisher keine Lösung dazu gefunden.

Gruß
Harald

[Renzo Bauen]

Hallo Harald
so viel ich weiss ist das kein Extbase sondern ein PHP Problem.
Vor ein paar Monaten gab es auf dieser Mailingliste schon einmal eine
Diskussion zu diesem Thema, habe aber den entsprechenden Thread gerade
nicht zum verlinken parat.
Beste Grüsse, Renzo
--
conPassione gmbh
CH-3661 Uetendorf
[phone]

[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.

Gruß
Harald

[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

[Harald Stanzel]

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

[Stephan Schuler]

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: [phone] - 0
E-Mail: ***@netlogix.de
Web: media.netlogix.de




netlogix GmbH & Co. KG
IT-Services | IT-Training | Media
Neuwieder Straße 10 | 90411 Nürnberg
Telefon: [phone] - 0 | Fax: [phone] - 99
E-Mail: ***@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-***@lists.typo3.org [mailto:typo3-german-***@lists.typo3.org] Im Auftrag von Harald Stanzel
Gesendet: Mittwoch, 11. März 2015 12:46
An: typo3-***@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-***@lists.typo3.org
http://lists.typo3.org/cgi-bin/mailman/listinfo/typo3-german

[Stephan Schuler]

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: [phone] - 0
E-Mail: ***@netlogix.de
Web: media.netlogix.de

- -----Ursprüngliche Nachricht-----
Von: typo3-german-***@lists.typo3.org [mailto:typo3-german-***@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: [phone] - 0
E-Mail: ***@netlogix.de
Web: media.netlogix.de




netlogix GmbH & Co. KG
IT-Services | IT-Training | Media
Neuwieder Straße 10 | 90411 Nürnberg
Telefon: [phone] - 0 | Fax: [phone] - 99
E-Mail: ***@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-***@lists.typo3.org [mailto:typo3-german-***@lists.typo3.org] Im Auftrag von Harald Stanzel
Gesendet: Mittwoch, 11. März 2015 12:46
An: typo3-***@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-***@lists.typo3.org
http://lists.typo3.org/cgi-bin/mailman/listinfo/typo3-german

* Stephan Schuler <***@netlogix.de>
* 0xC89B57C3(L)
_______________________________________________
TYPO3-german mailing list
TYPO3-***@lists.typo3.org
http://lists.typo3.org/cgi-bin/mailman/listinfo/typo3-german

[Harald Stanzel]

Hallo Stephan,

>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"

Auf deine Frage: Ich glaub, ich hatte es schonmal so ausprobiert. Soweit ich weiß, ist TCA nur fürs Backend zuständig.
Weil ich meine Eingaben aber im FE mache, denk ich, tut es nichts zur Sache.
Aber zur Sicherheit hab ich das grad nochmal nachgeschaut...

In Configuration/TCA/Person.php steht unter columns:
'birth_date' => array(
'exclude' => 0,
'label' => 'LLL:EXT:familytree/Resources/Private/Language/locallang_db.xlf:tx_familytree_domain_model_person.birth_date',
'config' => array(
'db_type' => 'date',
'type' => 'input',
'size' => 7,
'eval' => 'date',
'checkbox' => 1,
'default' => time()
),
),

In der ext_tables.sql lautet die entsprechende Stelle
CREATE TABLE tx_familytree_domain_model_person (
...
birth_date date DEFAULT '0000-00-00' NOT NULL, ...);

Und nach dem Test, was dabei passiert, stoße ich wieder auf das unter Problem2 genannte :
NULL-Value in beide Richtungen,d.h. phpmyadmin zeigt 0000-00-00 und wenn ich das dort editier, zeigt mein FE 1.1.1970 (sonst nichts)

:(

[Stephan Schuler]

Hallo Harald.

Nein, das TCA ist sowohl fürs Frontend als auch fürs Backend zuständig. Mit dem TCA wird grundsätzlich definiert, welches Datenbankschema TYPO3 verwenden soll, bzw. wie die Resultate zu interpretieren sind.
Einige Dinge, wie "eval" zum Beispiel, sind in erster Linie im Backend relevant weil im Frontend davon ausgegangen wird, dass Daten aus der Datenbank schon korrekt sein werden. Oder das "label" hat natürlich im Frontend überhaupt keine Relevanz.
Andere Dinge, und dazu gehört meines Wissens auch die dbType-Eigenschaft, sind sowohl für das Backend als auch für das Frontend notwendig. Oder aber zum Beispiel für den "type=>select" die Eigenschaft "foreignTable".

Vergleiche mal dein TCA-Fragment mit meinem Link. Die TCA-Eigenschaften sind relativ inkonsistenz benannt. Einige sind Kleinbuchstaben mit Unterstrichen, einige sind lowerCamelCase, wieder andere eine Mischung. Es gibt die "foreign_table", es gibt "maxitems", es gibt "fileFolder_extList".
Die "dbType"-Eigenschat schreibt sich wirklich lowerCamelCase.
Im Zweifelsfall einfach immer alles in der Dokumentation nachschlagen.

Übrigens: Wie sich das "default => time()" verhält kann ich dir gerade nicht sagen. Kann sein dass es richtig ist, ich würde aber eher von einer formatierten Datumsvariante ausgehen.

Kannst du bei der Gelegenheit bitte gleich mal prüfen, ob sowohl dein MySQL als auch dein PHP 64bit sind und dementsprechend die von mir in meiner letzten E-Mail genannten Werte grunsätzlich mit PHP erzeugt und mit MySQL gespeichert werden können?

Gruß,


Stephan Schuler
Web-Entwickler | netlogix Media

Telefon: [phone] - 0
E-Mail: ***@netlogix.de
Web: media.netlogix.de




netlogix GmbH & Co. KG
IT-Services | IT-Training | Media
Neuwieder Straße 10 | 90411 Nürnberg
Telefon: [phone] - 0 | Fax: [phone] - 99
E-Mail: ***@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



________________________________________
Von: typo3-german-***@lists.typo3.org <typo3-german-***@lists.typo3.org> im Auftrag von Harald Stanzel <***@web.de>
Gesendet: Mittwoch, 11. März 2015 19:04
An: typo3-***@lists.typo3.org
Betreff: Re: [TYPO3-german] wie handelt Extbase das Y2K38-Problem?

Hallo Stephan,

>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"

Auf deine Frage: Ich glaub, ich hatte es schonmal so ausprobiert. Soweit ich weiß, ist TCA nur fürs Backend zuständig.
Weil ich meine Eingaben aber im FE mache, denk ich, tut es nichts zur Sache.
Aber zur Sicherheit hab ich das grad nochmal nachgeschaut...

In Configuration/TCA/Person.php steht unter columns:
'birth_date' => array(
'exclude' => 0,
'label' => 'LLL:EXT:familytree/Resources/Private/Language/locallang_db.xlf:tx_familytree_domain_model_person.birth_date',
'config' => array(
'db_type' => 'date',
'type' => 'input',
'size' => 7,
'eval' => 'date',
'checkbox' => 1,
'default' => time()
),
),

In der ext_tables.sql lautet die entsprechende Stelle
CREATE TABLE tx_familytree_domain_model_person (
...
birth_date date DEFAULT '0000-00-00' NOT NULL, ...);

Und nach dem Test, was dabei passiert, stoße ich wieder auf das unter Problem2 genannte :
NULL-Value in beide Richtungen,d.h. phpmyadmin zeigt 0000-00-00 und wenn ich das dort editier, zeigt mein FE 1.1.1970 (sonst nichts)

:(
_______________________________________________
TYPO3-german mailing list
TYPO3-***@lists.typo3.org
http://lists.typo3.org/cgi-bin/mailman/listinfo/typo3-german

[Harald Stanzel]

Beide Daumen hoch! :)

Wer lesen kann, ist klar im Vorteil ;)
Mit 'dbType' und nicht 'db_type' funktioniert's !

Vom 1.1.1000 bis 31.12.9999 getestet.

>>> Kannst du bei der Gelegenheit bitte gleich mal prüfen, ob sowohl dein MySQL als auch dein PHP 64bit sind...?
Wollte ich schon lang mal...
WO find ich das denn?!

Wegen "default => time()" schau ich grad mal ins BE und sehe...
beim Anlegen einer neuen Person, steht der Datepicker auf 'heute'.
Der ist allerdings begrenzt auf 1901-2038, d.h. er zeigt zwar an, daß er beliebieg weit hoch und runter kann (sogar in negative Jahreszahlen), übernimmt aber keine Werte außerhalb.

Na, wenigstens scheint mein Problem gelöst zu sein. Da kann ich schon mal beruhigt zu Bett gehen ;)
Danke, bis dann!
Harald

[Stephan Schuler]

Die PHP-Konstante gibt es eine Konstante:
> echo PHP_INT_MAX

Für MySQL kannst du folgendes ausführen:
> SELECT
> ~0 as max_bigint_unsigned,
> ~0 >> 32 as max_int_unsigned,
> ~0 >> 40 as max_mediumint_unsigned,
> ~0 >> 48 as max_smallint_unsigned,
> ~0 >> 56 as max_tinyint_unsigned,
> ~0 >> 1 as max_bigint_signed,
> ~0 >> 33 as max_int_signed,
> ~0 >> 41 as max_mediumint_signed,
> ~0 >> 49 as max_smallint_signed,
> ~0 >> 57 as max_tinyint_signed
> ;

Aus den Zahlen darfst du dann ableiten, wie groß deine Integer maximal sein dürfen.


Stephan Schuler
Web-Entwickler | netlogix Media

Telefon: [phone] - 0
E-Mail: ***@netlogix.de
Web: media.netlogix.de




netlogix GmbH & Co. KG
IT-Services | IT-Training | Media
Neuwieder Straße 10 | 90411 Nürnberg
Telefon: [phone] - 0 | Fax: [phone] - 99
E-Mail: ***@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-***@lists.typo3.org [mailto:typo3-german-***@lists.typo3.org] Im Auftrag von Harald Stanzel
Gesendet: Mittwoch, 11. März 2015 21:37
An: typo3-***@lists.typo3.org
Betreff: Re: [TYPO3-german] wie handelt Extbase das Y2K38-Problem?

Beide Daumen hoch! :)

Wer lesen kann, ist klar im Vorteil ;)
Mit 'dbType' und nicht 'db_type' funktioniert's !

Vom 1.1.1000 bis 31.12.9999 getestet.

>>> Kannst du bei der Gelegenheit bitte gleich mal prüfen, ob sowohl dein MySQL als auch dein PHP 64bit sind...?
Wollte ich schon lang mal...
WO find ich das denn?!

Wegen "default => time()" schau ich grad mal ins BE und sehe...
beim Anlegen einer neuen Person, steht der Datepicker auf 'heute'.
Der ist allerdings begrenzt auf 1901-2038, d.h. er zeigt zwar an, daß er beliebieg weit hoch und runter kann (sogar in negative Jahreszahlen), übernimmt aber keine Werte außerhalb.

Na, wenigstens scheint mein Problem gelöst zu sein. Da kann ich schon mal beruhigt zu Bett gehen ;) Danke, bis dann!
Harald

_______________________________________________
TYPO3-german mailing list
TYPO3-***@lists.typo3.org
http://lists.typo3.org/cgi-bin/mailman/listinfo/typo3-german

[Harald Stanzel]

okay...

PHP_INT_MAX ist 2147483647 = 2^31-1
PHP Version 5.3.8

in sql ist das dann die max_int_signed
max_bigint_unsigned = 18446744073709551615 = 2^64 -1
max_bigint_signed = 9223372036854775807 = 2^63 -1
usw...

Scheint, als könne mysql mit 64 Bit umgehen, aber mein PHP nicht :/