Auf unserer Homepage veröffentlichen wir unter anderem auch historische Artikel. Nur leider ist es beim Datums-Feld von tt_news nicht möglich, ein Datum vor 1970 einzugeben.
Laut dem Posting unter
http://lists.netfielders.de/pipermail/typo3-at/2005-November/007363.html
liegt es daran, dass datetime in der ext_tables.sql als unsigned integer definiert ist. Meine Frage: auf was soll ich es umstellen, damit ich auch ein Datum wie zB 1915 verwenden kann, und trotzdem nicht riskiere, dass andere Funtionalitäten von tt_news beeinträchtigt werden?
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.
Es gibt da nur 2 Möglichkeiten:
Du modifizierst den Code von tt_news, so daß er einen negativen Wert in ein korrektes Datum umrechnet, bzw. setzt den Typ von unsigend int auf date_time um und paßt auch hier die programmierung an, oder
du lebst damit.
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.
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