Operation: Unix Datum 1970

[izanagi]

Prolog: Sämtliche Threads zum Thema habe hier durchgelesen und finde ausschließlich abgebrochene Recherchen oder Threader die garkeine Antwort bekommen haben

Vergangenheit: Was hat man sich damals bloß gedacht

Gegenwart: Ich sitz zwei Tagen an dem Problem das wohl einige kennen. Im Catalog ein Datumsfeld setzen und im FrontEnd 15.10.1965 eingeben, bewirkt das der
Eintrag nach einen Reload weg ist bzw. ersetzt wird mit 01.01.1970.

Leider versteh ich nicht so viel von PHP und kann da nicht eingreifen. Das Thema möchte ich gerne mit den Experten mal besprechen ob nicht endlich
eine Lösung gefunden werden kann

@ Mack
du hattest das Thema auch schon zweimal durchkauen müssen ^^ wurde da bereits irgendwas erfreuliches gefunden ?

VG

[melzebub]

klingt nach nem formatproblem. was steht denn in der Datenbank?

[magicsepp]

da fängt wahrscheinlich das Problem schon an... das date Feld ist ein unsigned int Feld, damit dürften schon mal alle negativen Zahlen also kleiner 01.01.1970 problematisch werden...
in der tl_member beim Feld dateofBirth hingegen wird ein varchar verwendet und da gehen auch negative Datumseinträge.

[izanagi]

Hallo ihr beiden.

Sowas in der Art habe ich mir auch gedacht, das hier der Catalog das Datum anders speichert bzw. verwertet als der Core.
Weil bei den Mitgliedseinträgen funktioniert es ja.

@ melzebub + magicsepp
genau wie ihr sagtet, Das Feld ist ein int(10) und "unsigned"
Aber integer hat doch negativzahlen oder hat das was mit dem unsigned zu tun da Grenzwert bei 0 ?!!?

Also beim Speichern eines Werts über 1970 bekomme ich einen Unix TImstamp zb. 304815600 (alter 33)
bei unter 1970 speichert er den Wert 0 Demnach also 1970


Was könnte man denn da jetzt machen?

[melzebub]

irre ich mich, oder kann es gar keinen kleineren timestamp als 1970 geben, da 1970 = 0. WEiß nicht wie gut sich das zum Geburtstag erfassen überhaupt eignet.

[fiedsch]

oder hat das was mit dem unsigned zu tun

klar hat das mit unsigned == Vorzeichenlos zu tun. Unsigned interger == "benutze das Vorzeichenbit für einen größeren (positiven) Wertebereich"

Zitat aus de mySQL Doku:

Integer normaler Größe. Der vorzeichenbehaftete Bereich liegt zwischen -2147483648 und 2147483647. Der vorzeichenlose Bereich liegt zwischen 0 und 4294967295.

Ohne mich mit Catalog näher auszukennen: Kann man das betroffene Feld nicht einfach als Textfeld definieren?

[magicsepp]

...
Aber integer hat doch negativzahlen oder hat das was mit dem unsigned zu tun da Grenzwert bei 0 ?!!?
...
Was könnte man denn da jetzt machen?

integer bestimmt die Zahlenrange und bei signed wird das oberste Bit für + und
- verwendet während bei unsigned der Zahlenraum bei 0 beginnt
Bsp.: signed char -128...+127 und
unsigned 0 ... 255 benutzt

Erstelle ein Ticket bei contao-forge ich könnte mir vorstellen das da einiges geändert werden muss.

[izanagi]

Ich kenn den int Gebrauch nur aus Actionscript. Aber jetzt wo du es erwähnst fällt es mir ein, in AS gibt auch den uint also den unsigned integer für nur positive.
Mein Hirn ist wohl etwas verrostet.

Ticket im contao-forge ? Ist das nicht aktuell in diesem gitHub oder wie das Ding heisst.
Ich hab noch nie ein Ticket aufgemacht

[magicsepp]

der catalog ist noch hier:

http://www.contao-forge.org/projects/catalog

[izanagi]

Dank eures Gedankenschubs hab ich es jetzt mal selbst gelöst.
In der config.php des Catalog ab Zeile 80 "date array" das Attribute "unsigned" raus genommen und das Problem ist gelöst.
Sollte man dann vielleicht in dem nächsten Catalog Release berücksichtigen. Es sei denn es MUSS so sein, vielleicht haben sich die Entwickler ja was bei gedacht. ?! i dont know