Re: [TYPO3-german] Datum wird nicht übernommen
Am 13.10.14 18:12, schrieb Uwe Siedentop: Hallo Bernd, das tt_news langsam nicht mehr gepflegt wird, habe ich schon mitbekommen. Aber ich habe schon so viele Seiten damit gemacht ... naja. Ich denke, es geht viel einfacher: In tt_news wurde das Feld datetime als int(11) angelegt. Ich habe das Feld einfach von int(11) auf bigint(11) erweitert. Jetzt kann ich die negativen Zahlen manuell abspeichern, wie ich es brauche. Es wird auch das Korrekte Datum im Frontend angezeigt. bigint(11)? bigint(20) wäre besser, da die Zahlen doch etwas größer sein könnten, aber die Anzeige erfolgt eigentlich niemals als integer-Zahl. Und was ich auf jeden fall auch noch einmal überprüfen würde: werden alle Daten korrekt gehandhabt? wissen die Routinen von Jahrhundert-(un)Schaltjahren? ist 28.2.1900 10:00:00 + 1 Tag = 1.3.1900 10:00:00 ? ist 28.2.1600 10:00:00 + 1 Tag = 29.2.1600 10:00:00 ? und was ist mit 1582? 4.10.1582 10:00:00 + 1 Tag = 15.10.1582 10:00:00 ! Datumsangaben (allein im Gregorianischen Kalender) können ein ziemliches Durcheinander sein. Und wenn dann unterschiedliche kalendersysteme zusammen kommen (oder auch Zeitzonen) ist das Chos perfekt. Allerdings macht jetzt der datepicker Probleme: Sobald die Zahl kleiner 1.1.1902 ist, schreibt er z. B. 31.12.2014 rein, ersetzt also das Jahr. ;-)). Weißt Du, wo man den datepicker finden kann? Ich würde ihn gerne abschalten oder, was besser wäre, erweiteren. Zum Abschalten oder wo der integriert ist habe ich im Netz leider nichts gefunden. tja. und damit verläßt du sicheres Terrain. der Datepicker ist Javascript und Javascript kennt keine longint/bigint/... und deaktivieren hat Phillip ja schon beantwortet. bernd -- http://www.pi-phi.de/cheatsheet.html ___ TYPO3-german mailing list TYPO3-german@lists.typo3.org http://lists.typo3.org/cgi-bin/mailman/listinfo/typo3-german
Re: [TYPO3-german] Datum wird nicht übernommen
Hallo Bernd., nachdem ich auf meinen Texten nicht weiter als vielleicht 1790 gehen muss, habe ich mit bigint(11) ausreichend Spielraum. Damit aber Deine Frage geklärt ist, habe ich auf bigint(22) erweitert und durchgespielt: Wenn ich den 1.März 1900 00:00:00 in Sekunden (-2203894800) eingebe, erscheint das richtige Datum. Zähle ich eine Skunde runter, kommt richtigerweise der 28.2.1900 23:59:59 (-2203894801). Das gleiche gilt für 1. März 1600 (-11670915600): Da das Jahr ein Schaltjahr ist, wird auch der 29. Februar 1600 23.59.59 angezeigt (-11670915601). Das bedeutet, dass einzig das JavaScript nicht mit dem Datum umgehen kann. Aber auch da denke ich, ist das Problem nicht der Umgang mit der negativen Zahl. Hier wird eher eine Abrage laufen, die besagt, dass wenn ein Datum älter als 1. Januar 1902 kommt, (durch Zugriff auf den beschränkten Systemdatumsumfang), er das nicht annehmen soll/kann und einfach auf das aktuelle Jahr umschaltet. Wenn ich da was finde, melde ich mich zurück. Vielen Dank für die konstruktiven Gespräche. Gruß Uwe Quote: Bernd Wilke[2] wrote on Tue, 14 October 2014 09:17 Am 13.10.14 18:12, schrieb Uwe Siedentop: Hallo Bernd, das tt_news langsam nicht mehr gepflegt wird, habe ich schon mitbekommen. Aber ich habe schon so viele Seiten damit gemacht ... naja. Ich denke, es geht viel einfacher: In tt_news wurde das Feld datetime als int(11) angelegt. Ich habe das Feld einfach von int(11) auf bigint(11) erweitert. Jetzt kann ich die negativen Zahlen manuell abspeichern, wie ich es brauche. Es wird auch das Korrekte Datum im Frontend angezeigt. bigint(11)? bigint(20) wäre besser, da die Zahlen doch etwas größer sein könnten, aber die Anzeige erfolgt eigentlich niemals als integer-Zahl. Und was ich auf jeden fall auch noch einmal überprüfen würde: werden alle Daten korrekt gehandhabt? wissen die Routinen von Jahrhundert-(un)Schaltjahren? ist 28.2.1900 10:00:00 + 1 Tag = 1.3.1900 10:00:00 ? ist 28.2.1600 10:00:00 + 1 Tag = 29.2.1600 10:00:00 ? und was ist mit 1582? 4.10.1582 10:00:00 + 1 Tag = 15.10.1582 10:00:00 ! Datumsangaben (allein im Gregorianischen Kalender) können ein ziemliches Durcheinander sein. Und wenn dann unterschiedliche kalendersysteme zusammen kommen (oder auch Zeitzonen) ist das Chos perfekt. Allerdings macht jetzt der datepicker Probleme: Sobald die Zahl kleiner 1.1.1902 ist, schreibt er z. B. 31.12.2014 rein, ersetzt also das Jahr. ;-)). Weißt Du, wo man den datepicker finden kann? Ich würde ihn gerne abschalten oder, was besser wäre, erweiteren. Zum Abschalten oder wo der integriert ist habe ich im Netz leider nichts gefunden. tja. und damit verläßt du sicheres Terrain. der Datepicker ist Javascript und Javascript kennt keine longint/bigint/... und deaktivieren hat Phillip ja schon beantwortet. bernd -- http://www.pi-phi.de/cheatsheet.html ___ TYPO3-german mailing list TYPO3-german@lists.typo3.org http://lists.typo3.org/cgi-bin/mailman/listinfo/typo3-german
Re: [TYPO3-german] Datum wird nicht übernommen
Am 10.10.14 16:42, schrieb Uwe Siedentop: Hallo Gert, Danke für Deine Anregung. Das mit dem Datum als String abspeichern und dann wieder als Datum ausgeben ist eigentlich nicht das Problem. Dazu habe ich bereits eine Klasse geschrieben, die mir alle eingebbare mir bekannte Datumsformate abfrägt und daraus dann ein einheitliches verarbeitbares Format bereitstellt. Das klappt hier auch an vielen Stellen wunderbar. So kann ich amerikanische, deutsche, schwäbische, bayerische oder andere Formate eingeben und bekomme an anderer Stelle wieder das Format, das da benötigt wird. Schwerigkeiten macht mir nur die Tatsache, dass ich z. B. in tt_news ein Datumsfeld habe, das aber nur bis 1.1.1902 zurückgeht, weil das Betriebssystem (übrigends ein 64 Bit Debian) nicht mehr verarbeiten kann. Und tt_news dieses Feld, das Erscheinungsdatum, aber intern zu Berechnungen verwendet: LATEST, List, AMENU verwenden dieses Datum/Feld. Und an dem Punkt stehe ich jetzt: Kann ich tt_news mit einer Ext so umbiegen, dass es ein anderes Feld, mit den neuen Spezifikationen, dazu verwendet? Aber ohne beim nächsten update wieder überschrieben zu werden ... Und dazu würde ich gerne die bereits bestehende Technik anwenden: Ab einem bestimmten Punkt - der Stunden Null - in Sekunden plus oder minus rechnen. So kann ich auf bestehende Programmierung zurückgreifen und wenn das Betriebssystem irgend wann mal erweitert würde, müsste ich nicht eine Konvertierung anwerfen ... 1. du solltest dir überlegen auf tx_news umzusteigen. für tt_news wird es keine updates (und erweiterungen) mehr geben. 2. sowohl für tt_news (diverse extension) als auch tx_news (Option im EM) gibt es die Möglichkeit anhand eines eigenen Feldes sorting manuell zu sortieren statt anhand von date. (Ich hatte es schon mal in diesem Thread erwähnt) bernd -- http://www.pi-phi.de/cheatsheet.html ___ TYPO3-german mailing list TYPO3-german@lists.typo3.org http://lists.typo3.org/cgi-bin/mailman/listinfo/typo3-german
Re: [TYPO3-german] Datum wird nicht übernommen
Hallo Bernd, das tt_news langsam nicht mehr gepflegt wird, habe ich schon mitbekommen. Aber ich habe schon so viele Seiten damit gemacht ... naja. Ich denke, es geht viel einfacher: In tt_news wurde das Feld datetime als int(11) angelegt. Ich habe das Feld einfach von int(11) auf bigint(11) erweitert. Jetzt kann ich die negativen Zahlen manuell abspeichern, wie ich es brauche. Es wird auch das Korrekte Datum im Frontend angezeigt. Allerdings macht jetzt der datepicker Probleme: Sobald die Zahl kleiner 1.1.1902 ist, schreibt er z. B. 31.12.2014 rein, ersetzt also das Jahr. ;-)). Weißt Du, wo man den datepicker finden kann? Ich würde ihn gerne abschalten oder, was besser wäre, erweiteren. Zum Abschalten oder wo der integriert ist habe ich im Netz leider nichts gefunden. Danke Uwe Quote: Bernd Wilke[2] wrote on Mon, 13 October 2014 08:40 Am 10.10.14 16:42, schrieb Uwe Siedentop: Hallo Gert, Danke für Deine Anregung. Das mit dem Datum als String abspeichern und dann wieder als Datum ausgeben ist eigentlich nicht das Problem. Dazu habe ich bereits eine Klasse geschrieben, die mir alle eingebbare mir bekannte Datumsformate abfrägt und daraus dann ein einheitliches verarbeitbares Format bereitstellt. Das klappt hier auch an vielen Stellen wunderbar. So kann ich amerikanische, deutsche, schwäbische, bayerische oder andere Formate eingeben und bekomme an anderer Stelle wieder das Format, das da benötigt wird. Schwerigkeiten macht mir nur die Tatsache, dass ich z. B. in tt_news ein Datumsfeld habe, das aber nur bis 1.1.1902 zurückgeht, weil das Betriebssystem (übrigends ein 64 Bit Debian) nicht mehr verarbeiten kann. Und tt_news dieses Feld, das Erscheinungsdatum, aber intern zu Berechnungen verwendet: LATEST, List, AMENU verwenden dieses Datum/Feld. Und an dem Punkt stehe ich jetzt: Kann ich tt_news mit einer Ext so umbiegen, dass es ein anderes Feld, mit den neuen Spezifikationen, dazu verwendet? Aber ohne beim nächsten update wieder überschrieben zu werden ... Und dazu würde ich gerne die bereits bestehende Technik anwenden: Ab einem bestimmten Punkt - der Stunden Null - in Sekunden plus oder minus rechnen. So kann ich auf bestehende Programmierung zurückgreifen und wenn das Betriebssystem irgend wann mal erweitert würde, müsste ich nicht eine Konvertierung anwerfen ... 1. du solltest dir überlegen auf tx_news umzusteigen. für tt_news wird es keine updates (und erweiterungen) mehr geben. 2. sowohl für tt_news (diverse extension) als auch tx_news (Option im EM) gibt es die Möglichkeit anhand eines eigenen Feldes sorting manuell zu sortieren statt anhand von date. (Ich hatte es schon mal in diesem Thread erwähnt) bernd -- http://www.pi-phi.de/cheatsheet.html ___ TYPO3-german mailing list TYPO3-german@lists.typo3.org http://lists.typo3.org/cgi-bin/mailman/listinfo/typo3-german
Re: [TYPO3-german] Datum wird nicht übernommen
Hi Uwe, Uwe Siedentop wrote: Weißt Du, wo man den datepicker finden kann? Ich würde ihn gerne abschalten oder, was besser wäre, erweiteren. Zum Abschalten oder wo der integriert ist habe ich im Netz leider nichts gefunden. Der Date Picker ist eingebunden, weil das Feld per TCA als Datums Feld konfiguriert ist: http://docs.typo3.org/typo3cms/TCAReference/Reference/Columns/Input/Index.html#columns-input-examples-date Grüße -- Philipp Gampe – PGP-Key 0AD96065 – TYPO3 UG Bonn/Köln Documentation – Active contributor TYPO3 CMS TYPO3 inspiring people to share! ___ TYPO3-german mailing list TYPO3-german@lists.typo3.org http://lists.typo3.org/cgi-bin/mailman/listinfo/typo3-german
Re: [TYPO3-german] Datum wird nicht übernommen
Am 09.10.14 17:56, schrieb Uwe Siedentop: Hallo Bernd, hallo Chris, da 95% aller Datumseingaben aktuell mit 32bit-signed-timestamps machbar sind wird es kaum neue Lösungen geben. so interpretiere ich das auch: Wir leben jetzt und nicht vor 150 Jahren ;-))) Aber ich denke, für TT, MM und Y ein eigenes Feld zu erzeugen ist wegen der schlechten Berechenbarkeit porblematisch. Dann versuche ich lieber, das Bestehende zu erweitern (unter Typo3). Spontane Idee: Wenn der 1.1.1902 unterschritten wird, die Sekunden in einem Extrafeld der Datenbank ablegen. Ist da ein Wert drin, bei der Ausgabe berücksichtigen und entsprechend ausgeben. Da es keinen Sinn macht, diese Erweiterung für den Normalgebauch einzusetzen (95% ...) wäre das, speziell jetzt bei mir, nur für das Erscheinungsdatumsfeld von tt_news notwendig. Wenn ich es schaffe, die Eigabe und Ausgabe abzufangen, könnte ich tt_news wie gewohnt einsetzen. Ich bin kein so großer Programmierer - aber reizen würde es mich ... Als Programmierer wüßtest du dass dieser Ansatz nur Komplikationen geben kann: wenn du Zusatzsekunden aufaddieren willst sprengst du mit der Addition sofort den Wertebereich (ansonsten könnte das Ergebnis ja direkt gespeichert werden) es wird also eine echte Alternative benötigt, die alle Funktionen abdeckt. in PHP gibt es den Datentyp Date, genauso wie in SQL. Nur für Anzeige und Verifikation reicht das schon. Kompliziert wird es dann wenn Differenzen berechnet werden sollen. und wenn evtl. noch Uhrzeiten berücksichtigt werden müssen, insbesondere Uhrzeiten mit Zeitzonen. Aber das sind dann schon wieder ganz besondere Fälle. ein Schalter Benutze alternatives Datumsfeld und dann ein alternatives aber einheitliches Datums-Handling ist einfacher zu realisieren als eine Mischung von std mit Erweiterung. So etwas könnte dann zb. auch für Geburtstage von Personen benutzt werden um historische Daten zu erfassen oder auch alle (Kalender-)Daten im Bereich Genealogie (Geburt, Hochzeit, Tod, ...). Das Date-Format hat zb. grundsätzlich den Vorteil Jahrestage einfacher handeln zu können (zb. sortierte Geburtstagsliste) bernd -- http://www.pi-phi.de/cheatsheet.html ___ TYPO3-german mailing list TYPO3-german@lists.typo3.org http://lists.typo3.org/cgi-bin/mailman/listinfo/typo3-german
Re: [TYPO3-german] Datum wird nicht übernommen
Hallo Bernd, es wäre natürlich sinnvoll, hier eine weitreichendere Lösung zu bekommen. Denn genau die von Dir aufgezählten Punkte sind die, die ich benötige: Historische Daten in vielen Beziehungen. Nur: Wo kann ich ansetzen, um diesen allumfassenden Ansatz zu realisieren? Ich benötige halt jetzt eine Möglichkeit, ältere Zeitangaben verarbeiten zu können. Und da sehe ich für mich keine zeitliche Perspektive. Als Programmierer wüßtest du dass dieser Ansatz nur Komplikationen geben kann: Die Komplikationen sind mir durchaus bekannt. Ich habe mir genau aus diesem Grund eine Klasse geschrieben, die mir unterschiedliche Zeit/Datumsformate entgegennehmen kann und ein Format ausgibt, das ich an einer bestimmten Stelle benötige. Nur habe ich mich da in einem Bereich bewegt, der nicht älter als +/- 20 Jahre betrifft. Auch sehe ich natürlich eine von mir skizzierte Extension als eine Art gebastel an, das nur als Übergangslösung dienen kann. Denn ich kann aus meiner Warter hier nicht bewirken, dass die Betriebssysteme auf Grund meiner Anforderungen geändert werden ;-))) ein Schalter Benutze alternatives Datumsfeld und dann ein alternatives aber einheitliches Datums-Handling ist einfacher zu realisieren als eine Mischung von std mit Erweiterung. OK. Das ganze Datum abzufangen um gleich in ein eigenes Feld zu schreiben wäre auch eine Alternative. Da habe ich allerdings zu wenig Einblick in die folgenden Anforderungen. Das müsste ich mich einarbeiten. Ich werde das mal anschauen und mich gegebenenfalls melden. Gruß Uwe Quote: Bernd Wilke[2] wrote on Fri, 10 October 2014 09:13 Am 09.10.14 17:56, schrieb Uwe Siedentop: Hallo Bernd, hallo Chris, da 95% aller Datumseingaben aktuell mit 32bit-signed-timestamps machbar sind wird es kaum neue Lösungen geben. so interpretiere ich das auch: Wir leben jetzt und nicht vor 150 Jahren ;-))) Aber ich denke, für TT, MM und Y ein eigenes Feld zu erzeugen ist wegen der schlechten Berechenbarkeit porblematisch. Dann versuche ich lieber, das Bestehende zu erweitern (unter Typo3). Spontane Idee: Wenn der 1.1.1902 unterschritten wird, die Sekunden in einem Extrafeld der Datenbank ablegen. Ist da ein Wert drin, bei der Ausgabe berücksichtigen und entsprechend ausgeben. Da es keinen Sinn macht, diese Erweiterung für den Normalgebauch einzusetzen (95% ...) wäre das, speziell jetzt bei mir, nur für das Erscheinungsdatumsfeld von tt_news notwendig. Wenn ich es schaffe, die Eigabe und Ausgabe abzufangen, könnte ich tt_news wie gewohnt einsetzen. Ich bin kein so großer Programmierer - aber reizen würde es mich ... Als Programmierer wüßtest du dass dieser Ansatz nur Komplikationen geben kann: wenn du Zusatzsekunden aufaddieren willst sprengst du mit der Addition sofort den Wertebereich (ansonsten könnte das Ergebnis ja direkt gespeichert werden) es wird also eine echte Alternative benötigt, die alle Funktionen abdeckt. in PHP gibt es den Datentyp Date, genauso wie in SQL. Nur für Anzeige und Verifikation reicht das schon. Kompliziert wird es dann wenn Differenzen berechnet werden sollen. und wenn evtl. noch Uhrzeiten berücksichtigt werden müssen, insbesondere Uhrzeiten mit Zeitzonen. Aber das sind dann schon wieder ganz besondere Fälle. ein Schalter Benutze alternatives Datumsfeld und dann ein alternatives aber einheitliches Datums-Handling ist einfacher zu realisieren als eine Mischung von std mit Erweiterung. So etwas könnte dann zb. auch für Geburtstage von Personen benutzt werden um historische Daten zu erfassen oder auch alle (Kalender-)Daten im Bereich Genealogie (Geburt, Hochzeit, Tod, ...). Das Date-Format hat zb. grundsätzlich den Vorteil Jahrestage einfacher handeln zu können (zb. sortierte Geburtstagsliste) bernd -- http://www.pi-phi.de/cheatsheet.html ___ TYPO3-german mailing list TYPO3-german@lists.typo3.org http://lists.typo3.org/cgi-bin/mailman/listinfo/typo3-german
Re: [TYPO3-german] Datum wird nicht übernommen
Am 10.10.14 10:56, schrieb Uwe Siedentop: ein Schalter Benutze alternatives Datumsfeld und dann ein alternatives aber einheitliches Datums-Handling ist einfacher zu realisieren als eine Mischung von std mit Erweiterung. OK. Das ganze Datum abzufangen um gleich in ein eigenes Feld zu schreiben wäre auch eine Alternative. Da habe ich allerdings zu wenig Einblick in die folgenden Anforderungen. Das müsste ich mich einarbeiten. Ich werde das mal anschauen und mich gegebenenfalls melden. ich würde tx_news um ein Date-feld erweitern. ob das intern tatsächlich als sql-date oder nur als String abgespeichert wird kann dann eigentlich egal sein. du brauchst eine (BE-)Eingabe mit Validator, so dass am Ende tatsächlich ein Datum gespeichert wird. (ein SQL-Date feld wird sich spätestens beim speichern gegen falsche Daten wehren, aber evtl. auch nur begrenzt (30.02.1801?) Ansonsten kann tx_news eigentlich komplett auf das date-feld verzichten: die Sortierung erfolgt manuell über sorting (Einstellung im EM) und es gibt halt kein archiv-datum. In den templates muss halt überall auf das neue Feld zugegriffen werden. vermutlich mit neuen Viewhelpern, die das neue Daten-Format statt timestamp benutzen können. bernd -- http://www.pi-phi.de/cheatsheet.html ___ TYPO3-german mailing list TYPO3-german@lists.typo3.org http://lists.typo3.org/cgi-bin/mailman/listinfo/typo3-german
Re: [TYPO3-german] Datum wird nicht übernommen
Uwe Siedentop schrieb: Hallo Bernd, es wäre natürlich sinnvoll, hier eine weitreichendere Lösung zu bekommen. Denn genau die von Dir aufgezählten Punkte sind die, die ich benötige: Historische Daten in vielen Beziehungen. Hallo Uwe, überlege Dir mal ein alternatives Konzept, bei dem Du ein beliebiges Datum abspeichern kannst und das auch in mysql indzieren kannst. Beispiel: die amerikanische Datums-Variante: der 28 Juli 1735 wäre zu konvertieren in ein ascii Feld (String) 1735.07.28 das geht dann rückwärts bis zum Jahr und vorwärts bis ich vermute, daß diese Zeitspanne wirklich ausreicht da Du ja auf die Uhrzeit keinen Wert legst, wäre nur die Eingabe abzuprüfen, das lesbare Datum in obigen String zu konvertieren und abzuspeichern bei der Ausgabe hast Du nur jeweils die Konvertierung in ein lesbares Format und das dann im jeweiligen Datumsfeld anzuzeigen. -- mit freundlichen Grüßen Dipl.Ing.Gert Redlich ___ TYPO3-german mailing list TYPO3-german@lists.typo3.org http://lists.typo3.org/cgi-bin/mailman/listinfo/typo3-german
Re: [TYPO3-german] Datum wird nicht übernommen
Hallo Gert, Danke für Deine Anregung. Das mit dem Datum als String abspeichern und dann wieder als Datum ausgeben ist eigentlich nicht das Problem. Dazu habe ich bereits eine Klasse geschrieben, die mir alle eingebbare mir bekannte Datumsformate abfrägt und daraus dann ein einheitliches verarbeitbares Format bereitstellt. Das klappt hier auch an vielen Stellen wunderbar. So kann ich amerikanische, deutsche, schwäbische, bayerische oder andere Formate eingeben und bekomme an anderer Stelle wieder das Format, das da benötigt wird. Schwerigkeiten macht mir nur die Tatsache, dass ich z. B. in tt_news ein Datumsfeld habe, das aber nur bis 1.1.1902 zurückgeht, weil das Betriebssystem (übrigends ein 64 Bit Debian) nicht mehr verarbeiten kann. Und tt_news dieses Feld, das Erscheinungsdatum, aber intern zu Berechnungen verwendet: LATEST, List, AMENU verwenden dieses Datum/Feld. Und an dem Punkt stehe ich jetzt: Kann ich tt_news mit einer Ext so umbiegen, dass es ein anderes Feld, mit den neuen Spezifikationen, dazu verwendet? Aber ohne beim nächsten update wieder überschrieben zu werden ... Und dazu würde ich gerne die bereits bestehende Technik anwenden: Ab einem bestimmten Punkt - der Stunden Null - in Sekunden plus oder minus rechnen. So kann ich auf bestehende Programmierung zurückgreifen und wenn das Betriebssystem irgend wann mal erweitert würde, müsste ich nicht eine Konvertierung anwerfen ... Gruß Uwe Quote: rdewiesbaden wrote on Fri, 10 October 2014 15:53 Uwe Siedentop schrieb: Hallo Bernd, es wäre natürlich sinnvoll, hier eine weitreichendere Lösung zu bekommen. Denn genau die von Dir aufgezählten Punkte sind die, die ich benötige: Historische Daten in vielen Beziehungen. Hallo Uwe, überlege Dir mal ein alternatives Konzept, bei dem Du ein beliebiges Datum abspeichern kannst und das auch in mysql indzieren kannst. Beispiel: die amerikanische Datums-Variante: der 28 Juli 1735 wäre zu konvertieren in ein ascii Feld (String) 1735.07.28 das geht dann rückwärts bis zum Jahr und vorwärts bis ich vermute, daß diese Zeitspanne wirklich ausreicht da Du ja auf die Uhrzeit keinen Wert legst, wäre nur die Eingabe abzuprüfen, das lesbare Datum in obigen String zu konvertieren und abzuspeichern bei der Ausgabe hast Du nur jeweils die Konvertierung in ein lesbares Format und das dann im jeweiligen Datumsfeld anzuzeigen. -- mit freundlichen Grüßen Dipl.Ing.Gert Redlich ___ TYPO3-german mailing list TYPO3-german@lists.typo3.org http://lists.typo3.org/cgi-bin/mailman/listinfo/typo3-german
[TYPO3-german] Datum wird nicht übernommen
Hallo zusammen, ich hoffe, ich bin hier mit meinem Anliegen richtig: Für eine Online-Dokumentation benötige ich Texte aus Zeitungen, die weit in die Vergangenheit zurückgehen - bis ca. 1820. Wenn ich jetzt den Kalender am Engabefeld nutze, kann ich zwar Monat und Jahr auswählen, wenn ich aber den Tag festlege, springt das Jahr immer auf 2014 zurück. Der Effekt tritt auch auf, wenn ich das Datum manuell eingebe. Gibt es da einen Patch oder weiß jemand, wie das verhindert werden kann? Ich verwende momentan Typo3 4.7.19. Der Effekt ist mir unter tt_news 3.6.0 und dann in den Seiteneigenschaften aufgefallen. Gruß Uwe ___ TYPO3-german mailing list TYPO3-german@lists.typo3.org http://lists.typo3.org/cgi-bin/mailman/listinfo/typo3-german
Re: [TYPO3-german] Datum wird nicht übernommen
Hallo Uwe Läuft dein Typo3 unter windows? Dann ist es warscheinlich ein Problem mit PHP (das vor 5.1 keine Timstamps vor 1970 auf Windows kannte) Allerdings begrenzen PHP-Versionen vor 5.1.0 den Bereich auf einigen Systemen (z.B. Windows) auf 1970-2038. - http://de1.php.net/manual/de/function.mktime.php Ansonsten würde ich auf das Datepicker Javascript tippen, das die dort irgendwo davon ausgehen das Timestamps Positiv sind. Und falls das nicht der fall ist das korregieren Gruss chris -Ursprüngliche Nachricht- Von: typo3-german-boun...@lists.typo3.org [mailto:typo3-german-boun...@lists.typo3.org] Im Auftrag von Uwe Siedentop Gesendet: Donnerstag, 9. Oktober 2014 11:35 An: typo3-german@lists.typo3.org Betreff: [TYPO3-german] Datum wird nicht übernommen Hallo zusammen, ich hoffe, ich bin hier mit meinem Anliegen richtig: Für eine Online-Dokumentation benötige ich Texte aus Zeitungen, die weit in die Vergangenheit zurückgehen - bis ca. 1820. Wenn ich jetzt den Kalender am Engabefeld nutze, kann ich zwar Monat und Jahr auswählen, wenn ich aber den Tag festlege, springt das Jahr immer auf 2014 zurück. Der Effekt tritt auch auf, wenn ich das Datum manuell eingebe. Gibt es da einen Patch oder weiß jemand, wie das verhindert werden kann? Ich verwende momentan Typo3 4.7.19. Der Effekt ist mir unter tt_news 3.6.0 und dann in den Seiteneigenschaften aufgefallen. Gruß Uwe ___ TYPO3-german mailing list TYPO3-german@lists.typo3.org http://lists.typo3.org/cgi-bin/mailman/listinfo/typo3-german ___ TYPO3-german mailing list TYPO3-german@lists.typo3.org http://lists.typo3.org/cgi-bin/mailman/listinfo/typo3-german
Re: [TYPO3-german] Datum wird nicht übernommen
Hallo Chris, Danke für Deine Antwort. Nein, Windows ist da nicht im Spiel: Linux san 3.2.0-4-amd64 #1 SMP Debian 3.2.60-1+deb7u3 x86_64 mit php 5.5.15. Ich denke auch, dass es der Datepicer ist. Das bedeutet : Auf UpDate hoffen?!? Ich schau mal, ob es bei Typo3 6.2 behoben ist. Wenn ja, dann werde ich eher da UpDaten. Ansonsten melde ich mich wieder hier. Nochmals Danke Uwe ___ TYPO3-german mailing list TYPO3-german@lists.typo3.org http://lists.typo3.org/cgi-bin/mailman/listinfo/typo3-german
Re: [TYPO3-german] Datum wird nicht übernommen
Hi Uwe, das heist ersmtal heraus bekommen ob es wirklich der datepicker ist das war ja nur ein wild guess. kann ja auch im Typo3 Core liegen das problem. oder daran das z.b die falsche Validierung in ext_tables.php für die Felder vergeben wurde. Etc... nicht den datepickre zu verwenden sondern dein datum manuell einzutragen. Wenn das erfolgreich geht ist es wohl der datpicker. Wenn es immer nicht geht ist es etwas anderes. Also erstmal grob einordnen wo das problem ist. Ansonsten natürlich im bugtracker schauen ob es schon eine fehlerbeschreibung zu dem problem gibt. Falls nein hinzufügen. Gruss chris -Ursprüngliche Nachricht- Von: typo3-german-boun...@lists.typo3.org [mailto:typo3-german-boun...@lists.typo3.org] Im Auftrag von Uwe Siedentop Gesendet: Donnerstag, 9. Oktober 2014 12:21 An: typo3-german@lists.typo3.org Betreff: Re: [TYPO3-german] Datum wird nicht übernommen Hallo Chris, Danke für Deine Antwort. Nein, Windows ist da nicht im Spiel: Linux san 3.2.0-4-amd64 #1 SMP Debian 3.2.60-1+deb7u3 x86_64 mit php 5.5.15. Ich denke auch, dass es der Datepicer ist. Das bedeutet : Auf UpDate hoffen?!? Ich schau mal, ob es bei Typo3 6.2 behoben ist. Wenn ja, dann werde ich eher da UpDaten. Ansonsten melde ich mich wieder hier. Nochmals Danke Uwe ___ TYPO3-german mailing list TYPO3-german@lists.typo3.org http://lists.typo3.org/cgi-bin/mailman/listinfo/typo3-german ___ TYPO3-german mailing list TYPO3-german@lists.typo3.org http://lists.typo3.org/cgi-bin/mailman/listinfo/typo3-german
Re: [TYPO3-german] Datum wird nicht übernommen
Am 09.10.14 11:34, schrieb Uwe Siedentop: Hallo zusammen, ich hoffe, ich bin hier mit meinem Anliegen richtig: Für eine Online-Dokumentation benötige ich Texte aus Zeitungen, die weit in die Vergangenheit zurückgehen - bis ca. 1820. Wenn ich jetzt den Kalender am Engabefeld nutze, kann ich zwar Monat und Jahr auswählen, wenn ich aber den Tag festlege, springt das Jahr immer auf 2014 zurück. Der Effekt tritt auch auf, wenn ich das Datum manuell eingebe. Gibt es da einen Patch oder weiß jemand, wie das verhindert werden kann? evtl. teilweise (für eingeschränkte Zeitbereiche). grundsätzlich aber nicht. TYPO3 benutzt für Zeitangebn das unix-timestamp-Format das eigentlich nur ein Delta in Sekunden seit 1.1.1970 0:00:00 speichert. inkl. negativen Zahlen funktioniert das dann im Bereich der Jahre 1901 - 2038 (13.12.1901 - 19.1.2038) da du aber Daten außerhalb dieses bereiches hast musst du soweiso ein anderes Format benutzen. grundsätzlich könntest du das date-format benutzen - abgesehen, dass es keine vernünftige Unterstützung in TYPO3 dafür gibt. Alternativ benutzt du einen String, ggfls mit dem Validation-Pattern 99.99.. eine interaktive Eingabe mit Kalendern fällt damit natürlich weg. bernd -- http://www.pi-phi.de/cheatsheet.html ___ TYPO3-german mailing list TYPO3-german@lists.typo3.org http://lists.typo3.org/cgi-bin/mailman/listinfo/typo3-german
Re: [TYPO3-german] Datum wird nicht übernommen
Hallo Uwe, ich glaube wir kommen deinem Problem Näher: 1. Unix Timestamp sind die Sekunden seit der Unix Epoche (ab.1970) Ich habe jetzt mal 1.1.1902 0:00 in einen unix timestamp convertiert: -2145916800 2) Habe ich mir angeschaut was der Minimal wert für einen vorzeichen behafteten 32 Bit Integer sind) -2147483647 (min wert für 32 bit Integer [13.12.1901 20:45:53]) -2145916800 (1.1.1902 00: als timestamp) Diese beiden werte liegen so nahe beieinander das ich glaube das du ein Problem mit 32 Bit Integern hast. Php sagt nun das die integer Plattform abhängig sind. The size of an integer is platform-dependent, although a maximum value of about two billion is the usual value (that's 32 bits signed). PHP does not support unsigned integers. Integer size can be determined using the constant PHP_INT_SIZE, and maximum value using the constant PHP_INT_MAX since PHP 4.4.0 and PHP 5.0.5. - http://php.net/manual/de/language.types.integer.php ich Vermute mal du Verwendest ein 32 Bit Betriebsystem / 32bit PHP Binary. Jetzt gibt es alo die möglichkeit ein Betriebsystem/php update auf 64 bit zu upgraden und zu hoffen das du dann längere integer hast. Eventuell musst du dann noch den Feld typ der Datenbank anpassen. (das ist kein problem! Wenn man es ordenlich macht ist das auch update stabil) Eine andere Alternative ist es tt_news um zusätzliche felder zu erweitern die jahr/monat/tag einzeln speichern dann fällst du nicht in den integer Overflow. Gruss chris -Ursprüngliche Nachricht- Von: typo3-german-boun...@lists.typo3.org [mailto:typo3-german-boun...@lists.typo3.org] Im Auftrag von Uwe Siedentop Gesendet: Donnerstag, 9. Oktober 2014 15:09 An: typo3-german@lists.typo3.org Betreff: [TYPO3-german] Re: Datum wird nicht übernommen Hallo Chris, hallo Bernd, vielen Dank für Eure Mühen. Es scheint so zu sein: Der Comuter (ob Linux, Windows oder OS) ignoriert alles was älter als 1.1.1902 ist. Das ist natürlich für mich, als Historiker, fatal: Ohne Eingriffe kann ich dann Typo3 nicht verwenden. Einen manuellen Eingriff sehe ich aber schlicht und ergreifend als nicht machbar an: Viele solcher Eingriffe haben mir beim nächsten Update das Leben ziemlich erschwert ... Wenn das dann jetzt so ist, ist vielleicht ein Ansatz eine eigene Extension zu bauen, die - speziell jetzt in tt_news - ein zusätzliches Feld zur Verfügung stellt, das dann das Erschenungsdatum als Text aufnimmt. Evtl. noch eine Formatprüfung, damit das Feld möglichst gleichbleibendes Format liefert. Das bestehende Feld ist dann das Erfassungdatum, das neue das Erscheinugsdatum. Mal sehen, ob ich den Ansatz weiterverfolge. Nochmals Vielen Dank Uwe ___ TYPO3-german mailing list TYPO3-german@lists.typo3.org http://lists.typo3.org/cgi-bin/mailman/listinfo/typo3-german ___ TYPO3-german mailing list TYPO3-german@lists.typo3.org http://lists.typo3.org/cgi-bin/mailman/listinfo/typo3-german
Re: [TYPO3-german] Datum wird nicht übernommen
Am 09.10.14 15:08, schrieb Uwe Siedentop: Hallo Chris, hallo Bernd, vielen Dank für Eure Mühen. Es scheint so zu sein: Der Comuter (ob Linux, Windows oder OS) ignoriert alles was älter als 1.1.1902 ist. Das ist natürlich für mich, als Historiker, fatal: Ohne Eingriffe kann ich dann Typo3 nicht verwenden. Einen manuellen Eingriff sehe ich aber schlicht und ergreifend als nicht machbar an: Viele solcher Eingriffe haben mir beim nächsten Update das Leben ziemlich erschwert ... Wenn das dann jetzt so ist, ist vielleicht ein Ansatz eine eigene Extension zu bauen, die - speziell jetzt in tt_news - ein zusätzliches Feld zur Verfügung stellt, das dann das Erschenungsdatum als Text aufnimmt. Evtl. noch eine Formatprüfung, damit das Feld möglichst gleichbleibendes Format liefert. Das bestehende Feld ist dann das Erfassungdatum, das neue das Erscheinugsdatum. Mal sehen, ob ich den Ansatz weiterverfolge. unter dem Aspekt der anstehenden Updates wäre zu überlegen ob du nicht auf tx_news umstellst und deine Feld-Erweiterung dafür unter 6.2 erstellst. bernd -- http://www.pi-phi.de/cheatsheet.html ___ TYPO3-german mailing list TYPO3-german@lists.typo3.org http://lists.typo3.org/cgi-bin/mailman/listinfo/typo3-german
Re: [TYPO3-german] Datum wird nicht übernommen
Am 09.10.14 15:47, schrieb Chris Wolff - AERTiCKET AG: Hallo Uwe, ich glaube wir kommen deinem Problem Näher: 1. Unix Timestamp sind die Sekunden seit der Unix Epoche (ab.1970) Ich habe jetzt mal 1.1.1902 0:00 in einen unix timestamp convertiert: -2145916800 2) Habe ich mir angeschaut was der Minimal wert für einen vorzeichen behafteten 32 Bit Integer sind) -2147483647 (min wert für 32 bit Integer [13.12.1901 20:45:53]) -2145916800 (1.1.1902 00: als timestamp) Diese beiden werte liegen so nahe beieinander das ich glaube das du ein Problem mit 32 Bit Integern hast. Php sagt nun das die integer Plattform abhängig sind. The size of an integer is platform-dependent, although a maximum value of about two billion is the usual value (that's 32 bits signed). PHP does not support unsigned integers. Integer size can be determined using the constant PHP_INT_SIZE, and maximum value using the constant PHP_INT_MAX since PHP 4.4.0 and PHP 5.0.5. - http://php.net/manual/de/language.types.integer.php ich Vermute mal du Verwendest ein 32 Bit Betriebsystem / 32bit PHP Binary. Jetzt gibt es alo die möglichkeit ein Betriebsystem/php update auf 64 bit zu upgraden und zu hoffen das du dann längere integer hast. Eventuell musst du dann noch den Feld typ der Datenbank anpassen. (das ist kein problem! Wenn man es ordenlich macht ist das auch update stabil) und spätestens bei der Eingabe mit Javascript-Unterstützung (Kalender-Tool oder Validierung) fällt das ganze auf die Nase weil es in absehbarer Zeit keine longints in Javascript geben wird. Diese Probleme und die entsprechenden Fazits sind aber schon seit einiger Zeit bekannt. da 95% aller Datumseingaben aktuell mit 32bit-signed-timestamps machbar sind wird es kaum neue Lösungen geben. insbesondere unter dem Aspekt, dass mit echten Datumsformaten schlecht (kompliziert) gerechnet werden kann (berechne: heute + 1,2,3,4,.. Wochen) bernd -- http://www.pi-phi.de/cheatsheet.html ___ TYPO3-german mailing list TYPO3-german@lists.typo3.org http://lists.typo3.org/cgi-bin/mailman/listinfo/typo3-german
Re: [TYPO3-german] Datum wird nicht übernommen
Hallo Bernd, hallo Chris, da 95% aller Datumseingaben aktuell mit 32bit-signed-timestamps machbar sind wird es kaum neue Lösungen geben. so interpretiere ich das auch: Wir leben jetzt und nicht vor 150 Jahren ;-))) Aber ich denke, für TT, MM und Y ein eigenes Feld zu erzeugen ist wegen der schlechten Berechenbarkeit porblematisch. Dann versuche ich lieber, das Bestehende zu erweitern (unter Typo3). Spontane Idee: Wenn der 1.1.1902 unterschritten wird, die Sekunden in einem Extrafeld der Datenbank ablegen. Ist da ein Wert drin, bei der Ausgabe berücksichtigen und entsprechend ausgeben. Da es keinen Sinn macht, diese Erweiterung für den Normalgebauch einzusetzen (95% ...) wäre das, speziell jetzt bei mir, nur für das Erscheinungsdatumsfeld von tt_news notwendig. Wenn ich es schaffe, die Eigabe und Ausgabe abzufangen, könnte ich tt_news wie gewohnt einsetzen. Ich bin kein so großer Programmierer - aber reizen würde es mich ... Gruß Uwe Quote: Bernd Wilke[2] wrote on Thu, 09 October 2014 16:04 Am 09.10.14 15:47, schrieb Chris Wolff - AERTiCKET AG: Hallo Uwe, ich glaube wir kommen deinem Problem Näher: 1. Unix Timestamp sind die Sekunden seit der Unix Epoche (ab.1970) Ich habe jetzt mal 1.1.1902 0:00 in einen unix timestamp convertiert: -2145916800 2) Habe ich mir angeschaut was der Minimal wert für einen vorzeichen behafteten 32 Bit Integer sind) -2147483647 (min wert für 32 bit Integer [13.12.1901 20:45:53]) -2145916800 (1.1.1902 00: als timestamp) Diese beiden werte liegen so nahe beieinander das ich glaube das du ein Problem mit 32 Bit Integern hast. Php sagt nun das die integer Plattform abhängig sind. The size of an integer is platform-dependent, although a maximum value of about two billion is the usual value (that's 32 bits signed). PHP does not support unsigned integers. Integer size can be determined using the constant PHP_INT_SIZE, and maximum value using the constant PHP_INT_MAX since PHP 4.4.0 and PHP 5.0.5. - http://php.net/manual/de/language.types.integer.php ich Vermute mal du Verwendest ein 32 Bit Betriebsystem / 32bit PHP Binary. Jetzt gibt es alo die möglichkeit ein Betriebsystem/php update auf 64 bit zu upgraden und zu hoffen das du dann längere integer hast. Eventuell musst du dann noch den Feld typ der Datenbank anpassen. (das ist kein problem! Wenn man es ordenlich macht ist das auch update stabil) und spätestens bei der Eingabe mit Javascript-Unterstützung (Kalender-Tool oder Validierung) fällt das ganze auf die Nase weil es in absehbarer Zeit keine longints in Javascript geben wird. Diese Probleme und die entsprechenden Fazits sind aber schon seit einiger Zeit bekannt. da 95% aller Datumseingaben aktuell mit 32bit-signed-timestamps machbar sind wird es kaum neue Lösungen geben. insbesondere unter dem Aspekt, dass mit echten Datumsformaten schlecht (kompliziert) gerechnet werden kann (berechne: heute + 1,2,3,4,.. Wochen) bernd -- http://www.pi-phi.de/cheatsheet.html ___ TYPO3-german mailing list TYPO3-german@lists.typo3.org http://lists.typo3.org/cgi-bin/mailman/listinfo/typo3-german
