Datum vor 1970 bei tt_news

naja, so wichtig ist es dann doch nicht. aber 1970 bis 2037 scheint mir ein recht schmaler zeitraum. doch da soll sich wer anderer gedanken machen.

Naja, bis 2037 ist noch ein wenig hin und bis dahin, wird der Integer auf 64-bit umgestellt, dann haben wir wieder Ruhe bis 292.000.000.000.
Das Problem liegt, wie schon beschrieben bei Typo: Das speichert seine Datumswerte leider als einen Timestamp, und das nicht mal als MySQL-Typ "timestamp". Vorteil ist natürlich die Unabhängigkeit vom eingesetzten SQL-Dialekt.
Nachteil: siehst ja selbst.

Übrigens hat Bernhard Kraft in einem Österreich-Forum mal ne Lösung geschickt:

Man muß die Datei
t3lib/jsfunc.evalfield.js
ändern.

Dann klappts.
Mal dem Link:
http://lists.netfielders.de/pipermail/typo3-at/2006-January/007491.html
folgen.

PS: Gut der Mann!!!!

hab das ausprobiert - für tt_news fuktioniert das nicht sofort. wahrscheinlich ist da noch was umzustellen.

Schon beim Eingeben nicht oder erst beim Speichern ?
Bei tt_news ist in der tca.php noch upper/lower gesetzt. Das müßte man wohl auch noch ändern.

Übrigens: bei Änderungen an oben genannter js-Datei mußt noch einen Reload des Browsers machen.Mußte ich jedenfalls.

Waldo

Der Tip kann nicht funktionieren, da auch die Datenbank geändert werden müßte.

Man wird zwar ein Datum vor 1970 eingeben können, beim speichern wirds dann aber schief gehen!

Also ich habe es ausprobiert auf einem Linux Server mit T3 3.8.1.
Es geht. Auch beim Speichern, bzw. nach dem Speichern ist alles OK.

bei mir klappts nicht - wenn ich mit einem datum zB aus 1905 speichern will erscheint "102: These fields are not properly updated in database: (datetime) Probably value mismatch with fieldtype." ich hab auch einen sehr konkreten verdacht: in der ext_tables.sql ist datetime als unsigned integer definiert. da gibts keine minuszahlen. ich bin kein mathematiker, aber wenn ich diversen webseiten glauben schenken kann, dann würde ein umstellen auf signed integer nur eine verschiebung des gleich großen zahlenraums um die hälfte nach hinten bedeuten, d.h. 2037-1970=67 67/2= 33,5 und 1970+33,5=2003,5 ; 1970-33,5=1936,5 => Zeitraum von Juni 1936 bis Juni 2003 - das ist mir wieder nicht groß genug. um die aktuellen artikel von 2006 keiner gefahr auszusetzen hab ich da darum nicht herumprobiert. hoffe, da kann jemand was dazu sagen.

Ok, ich sags nochmal:

woida schrieb

Das ist IMHO nicht möglich; Die Spalte Datetime müßte von der Semantik in MySQL als Timestamp abgebildet werden, ein UNIX-Zeitstempel also.
Der beginnt am 1.1.1970 (was dem Zeitstempel 0 entspricht) zu zählen und läuft 2037 über. Negative Werte sind nicht vorgesehen.

sry, aber heisst news nicht Neuigkeiten ? vll schreibt ja mal einer ne tt_olds ...

Mag sein, daß negative Werte nicht vorgesehen sind, aber es funktioniert. So lange keine bessere Lösung in Sicht ist, nehme ich das mal als Lösung an.
Ich hatte nämlich das Problem, daß ich en Geburtsdatum vor 1970 eingeben konnte.
Nach den bschriebenen Änderungen gehts.

Waldo

Übrigens: Datum/Zeit-Felder sind in TYPO klugerweise nicht als DateTime gespeichert, sonder als int(11). Und die dürfen negativ sein.

Ich möchte jeden, der nicht 100% weiß was er tut, warnen, den Tip/Patch auszuprobieren!

Übrigens: Datum/Zeit-Felder sind in TYPO klugerweise nicht als DateTime gespeichert, sonder als int(11). Und die dürfen negativ sein.

Das ist nicht ganz richtig! Das Feld wird als unsigned int gespeichert und da sind keine negativen Werte zugelassen. Du hast anscheinend den Feldtyp geändert, wenn man das nicht tut bekommt man nämlich den Fehler den slp-web bekommen hat.

Das stimmt allerdings. Man müßte das unsigned aus dem SQL-Create rausschmeißen.
Ansonsten gehts aber.
Nicht falsch verstehen: Ich halte die Lösung nicht für glücklich, aber ich weiß keine bessere.
Lasse mich aber gerne von einer besseren Lösung überzeugen.

Waldo