Zeiten in Normalzeit speichern und ausgeben

[Bernd.P]

Moin Moin,

freundlicherweise werden ja Zeiten auf dem Server als UTC-0 Timestamp abgelegt. Da ich mit den Integer-Werten weiter gerechnet habe fehlte mir natürlich immer eine Stunde. Wie geht man den in Contao denn damit um?
Sprich, eine Zeit für Sommer nächsten Jahres, die ich jetzt speichere, würde dann nächste Jahr nicht mehr stimmen.

Oder wie oder was?!?!

Gruß genervter Bernd

[mvo]

Ich hab zwar keine Ahnung was du zu erreichen versuchst, aber du solltest niemals händisch mit Timestamps/Daten rechnen. Dafür gibt es Bibliotheken & Funktionen.

(Und das Contao Timestamps verwendet statt echten Date Fields ist auch unschön, leider aber ohne Breaking Changes kaum änderbar.)

[Bernd.P]

Na, vielleicht habe ich mich nicht richtig ausgedrückt.
Ich habe drei Felder:

BE -- Wert in der Datenbank
Datum: 24.12.2017 -- 1514070000
StartZeit: 10:00 -- 32400 bei 32400/3600 = 9:00Uhr
Endzeit: 18:00 -- 61200 bei 61200/3600 = 17:00 Uhr

Bei UTC+1 würde ja im Augenblick die richtige Zeit im BE/FE ausgegeben werden.

Wenn ich jetzt das gleiche für den

Datum: 01.04.2018 -- 1522533600
StartZeit: 10:00 -- 32400 bei 32400/3600 = 9:00Uhr
Endzeit: 18:00 -- 61200 bei 61200/3600 = 17:00 Uhr

nehme, müsste die Sommerzeit am 01.04.2018 im BE/FE statt 10:00 Uhr 11:00Uhr ausgegeben werden, oder sehe ich das falsch?


Der Hintergrund des Ganzen ist, ich wollte wie bei einem Kalender einen Zeitblock vertikal positionieren und hatte dazu den Integerwert der StartZeit aus der Datenbank genommen. Dabei fiel ich über Zeit und blieb liegen.

[Bernd.P]

Obwohl ich die Gleichen Feld-Definitionen wie in der tl_calendar_event habe, wird bei mir auch nur der reine Stunden-Anteil gespeichert.

tl_calendar_event
tl_calendar_event.PNG

meine tl
tl_course_info.PNG

mehr misteriös

[Spooky]

Sieh dir das DCA genauer an. tl_calendar_events hat für diese Felder einen callback der das Datum dazu addiert.

[Bernd.P]

Sieh dir das DCA genauer an. tl_calendar_events hat für diese Felder einen callback der das Datum dazu addiert.

OK, das Misterium ist gelöst...

... und mein Denkfehler mit der Sommerzeit?

[Spooky]

Mysterium

Bzgl.: Sommer/Winterzeit - dazu verstehe ich dein Vorhaben zu wenig.

[Samson1964]

Vermutlich dasselbe Problem wie bei mir damals: https://community.contao.org/de/show...epicker-falsch

[Bernd.P]

Mysterium

Bzgl.: Sommer/Winterzeit - dazu verstehe ich dein Vorhaben zu wenig.

Also, wenn ich heute einen Termin mit den Datum 01.04.2018 12:00 Uhr speichre, wird er auf dem Server wegen GMT+1 als 01.04.2017 11:00 Uhr abgelegt. Nächstes Jahr am 01.04.2018 schaue ich mir den Termin an. In der Datenbank steht ja immer noch 01.04.2018 11:00 Uhr. Aber, dann müsste er mir doch auf Grund der Sommerzeit GMT+2 als 01.04.2018 13:00 Uhr angezeigt werden.

Oder bin ich auf dem Holzweg?

[Spooky]

Also, wenn ich heute einen Termin mit den Datum 01.04.2018 12:00 Uhr speichre, wird er auf dem Server wegen GMT+1 als 01.04.2017 11:00 Uhr abgelegt.

Welcher Timestamp für "01.04.2018 12:00:00" abgespeichert wird hängt davon ab welche Zeitzone du für deine Contao Installation konfiguriert hast. Hast du zB. die CET eingestellt, würde der Timestamp 1522580400 abgespeichert werden. Das entspricht Sunday, 01-Apr-18 11:00:00 UTC oder eben Sunday, 01-Apr-18 12:00:00 UTC+1 (= CET).

[Bernd.P]

Sag ich ja,

nächstes Jahr im Sommer entspricht 1522580400 --> 01.04.2018 um 13:00:00 Uhr (da UTC+2) und ich werde dann zu spät zum Essen kommen. :-(

[Spooky]

Sorry, richtiger Timestamp ist natürlich 1522576800. Das entspricht Sunday, 01-Apr-18 10:00:00 UTC bzw. Sunday, 01-Apr-18 12:00:00 UTC+2 (= CET DST).

[Bernd.P]

Das ist mir alles nicht geheuer, werde die Datumsfelder jetzt (versuchen) als String abzuspeichern.

Was machen denn die Datumsfelder, wenn nächstes Jahr die Sommerzeit abgeschaft werden würde, dann stimmt ja kein Unix-Kalender mehr?

[Spooky]

Was machen denn die Datumsfelder, wenn nächstes Jahr die Sommerzeit abgeschaft werden würde, dann stimmt ja kein Unix-Kalender mehr?

Nein, du missverstehst wie Timestamps funktionieren . Ein Unix Timestamp ist universell und unabhängig. Ein Unix Timestamp zählt die vergangenen Sekunden seit Donnerstag, dem 1. Januar 1970, 00:00 Uhr UTC.

Wenn du einen Unix Timestamp in eine für den Menschen lesbares oder verständliches Format bringen willst, musst du die Zeitzone definieren. Würde nächstes Jahr die Sommerzeit abgeschafft werden, ist auch das in dieser Definition enthalten.

[Bernd.P]

Ich glaube da täuscht du dich, wenn ich heute einen Datum eingebe, errechnet der Server ja Anhand der Zeitzone/Sommerzeit welcher Timestamp gespeichert wird, also für nächstes Jahr: 01.April -2 Stunden und fertig. Sollte die Sommerzeit wegfallen haben wir 1.April nur noch GMT+1 --> Timestamp +1Std und alle Termine platzen. Der Wert in der Datenbank ist ja schließlich immer noch der Gleiche.

[fiedsch]

Das klingt richtig, aber die Sommerzeit wird auch nicht einfach mal so schnell abgeschafft. Und wenn ich (die Software) heute schon weiß, daß es sie nächstes Jahr nicht mehr geben wird, dann kann ich das auch berücksichtigen.

[Spooky]

Ich glaube da täuscht du dich, wenn ich heute einen Datum eingebe, errechnet der Server ja Anhand der Zeitzone/Sommerzeit welcher Timestamp gespeichert wird, also für nächstes Jahr: 01.April -2 Stunden und fertig. Sollte die Sommerzeit wegfallen haben wir 1.April nur noch GMT+1 --> Timestamp +1Std und alle Termine platzen. Der Wert in der Datenbank ist ja schließlich immer noch der Gleiche.

Ja, und da der Wert immer noch der Gleiche ist, kann er auch wieder korrekt transformiert werden, theoretisch. Würde also die Sommerzeit nächstes Jahr plötzlich wegfallen, wüssten auch die entsprechenden Funktionen davon (vorausgesetzt die nötige Software wird dahingehen aktualisiert), wie fiedsch schon sagt.

[Bernd.P]

Na gut, ich gebe mich geschlagen. Finde dieses transformieren trotzdem eine unglückliche Lösung. Ich bin einfach für neues Datumsfeld, in dem nur das drin steht was auch rein sollte.
Aber für meine Hi-Tech-Erweiterung mit ihren 50 Zeile Code sollte ich jetzt über die Runden kommen. Danach wird sich mein Ausflug in die PHP-Welt erledigt haben und ich wechsel wieder in die Contao-Anwender-Welt.

[Spooky]

Das wird sich erst in Contao 5 ändern. Siehe auch https://github.com/contao/core/issues/8101

[Bernd.P]

OK einen habe ich noch. Beim vertippen habe festgestellt, dass ich im Contao-Kalender keine Starzeit < 1:00 Uhr eingeben kann.

Fehler: An exception occurred while executing 'UPDATE tl_calendar_events SET startTime=-1800 WHERE..


Fehler.PNG


Was soll mir das denn sagen?

Version ist die aktuelle Contao 4.4.9

[Spooky]

Kann ich in der Contao Online Demo nicht nachvollziehen - allerdings läuft die noch auf Contao 4.4.8.

[Bernd.P]

Werde ich erst einmal ignorieren, wahrscheinlich habe ich mit meinen Versuchen den Server beleidigt. Die 3.5er auf dem gleichen Server hat das Problem nicht.

[Spooky]

Auch in einer Contao 4.4.9 Installation kann ich das nicht nachvollziehen.

[Bernd.P]

Auch in einer Contao 4.4.9 Installation kann ich das nicht nachvollziehen.

Das Problem tritt auf wenn du in den Contao-Einstellungen die Zeitzone von "GMT" auf "Europa/Berlin" änderst und irgendetwas unter 1:00 Uhr eingeben möchtest.

Jetzt wäre eine Übersicht schön, was man wie in Contao/Webserver in Sachen Zeitzone richtig einstellen muss.


.

[Spooky]

Eine Umstellung der Zeitzone wirkt sich nur auf bestehende Termine negativ aus (siehe Link). Ich kann dein Problem also immer noch nicht nachvollziehen.

Prinzipiell musst du in Contao die Zeitzone einstellen, in der sich deine Website "befindet" (nicht die physische Location des Servers). In den PHP Einstellungen des Webservers sollte die richtige Zeitzone konfiguriert sein, nach der sich die Systemzeit des Servers richtet.

[Bernd.P]

Eine Umstellung der Zeitzone wirkt sich nur auf bestehende Termine negativ aus

Naja, "nur" ist gut. Tippe mal bei Contao ist standardmäßig "GMT" eingestellt. Sollte also jemand nach ein paar Jahren auf die Idee kommen auf Berlin umzustellen, dürfte das Geschrei groß sein.

Ich installiere Contao mal neu und teste ob es bei mir an irgendwelchen Erweiterungen liegt.

[Spooky]

Tippe mal bei Contao ist standardmäßig "GMT" eingestellt.

Nein, Standard Einstellung ist die im Webserver definierte Zeitzone.

[Bernd.P]

Habe gerade eine neue Contao 4.4.9 Installation aufgesetzt.
Vorher die Zeitzone im Webserver auf "Europa/Berlin" gestellt - wurde jetzt auch als Default in Contao übernommen.
Alles auf Grundeinstellung gelassen -> neue Seite eingerichtet usw.

...gleiche Fehlermeldung!

Sind also keine der Erweiterungen Schuld.


Werde den Fehler erst einmal ignorieren und morgen beim Provider(NetCup) anrufen. Vielleicht habe ich ja etwas am Webserver verstellt.

Termine zur Geisterstunde sollten bei uns eigentlich auch nicht vor kommen.


Nachtrag: wenn ich "Vladivostok" als Zeitzone in Contao nehme, kann ich keine Zeit < 10:00 Uhr eingeben. !?!?!?!

[Spooky]

Du könntest das als Bug im calendar-bundle mit genauen Reproduktionsschritten reporten.

[Bernd.P]

Also, ich habe jetzt Contao bei 1und1 neu aufgesetzt und einmal neu bei NetCup...
Bei 1und1 keine Probleme. In welche Zeitzone auch immer; bei NetCup läuft es nicht.

Ich habe dann bei NetCup den Timestamp für 00:30(UTC+1) mal direkt in die Datenbank gespeichert und siehe da, die Zeit wird im FE wie BE richtig als 00:30 angezeigt. Wenn ich dann aber versuche die 00:30 zwischen 00:01 und 00:59 zu ändern - gleiche Fehlermeldung.

So, für mich ist da jetzt erst einmal Schluss. Bis auf die Geisterstunde werden die Zeiten ja richtig gespeichert.

[Spooky]

Könntest du wie gesagt als Bug im calendar-bundle reporten.

[Bernd.P]

Immerhin bin ich schon mal unschuldig. Bei Netcup konnte der Fehler immerhin von noch jemanden reproduziert werden...

[Bernd.P]

Das kommt mir verdächtig vor. In der tl_calendar_event gibt es neuerdings einen Callback:

		'startTime' => array
		(
			'label'                   => &$GLOBALS['TL_LANG']['tl_calendar_events']['startTime'],
			'default'                 => time(),
			'exclude'                 => true,
			'filter'                  => true,
			'sorting'                 => true,
			'flag'                    => 8,
			'inputType'               => 'text',
			'eval'                    => array('rgxp'=>'time', 'mandatory'=>true, 'doNotCopy'=>true, 'tl_class'=>'w50'),
			'load_callback' => array
			(
				array('tl_calendar_events', 'loadTime')
			),
			'sql'                     => "int(10) unsigned NULL"
		),




	public function loadTime($value)
	{
		return strtotime('1970-01-01 ' . date('H:i:s', $value));
	}

den gab es in der 3.5 noch nicht... der würde für 00:30 Uhr -> -1800 auswerfen. Liegt vielleicht da das Problem?

[Bernd.P]

im GitHub gibt es den Callback auch nicht... https://github.com/contao/core/blob/...vents.php#L215

Ja, wo hab ich den denn her?

[Spooky]

Du bist im falschen Repository: https://github.com/contao/calendar-b....php#L225-L228

[Bernd.P]

Schade, ich dachte ich hätte etwas gefunden

[Nicolai]

Ich arbeite mit Contao 4.13.32 und bislang dachte ich, dass ich mich bei Terminen mal vertippt hätte.
Dieses Jahr habe ich die Termine für den Winter allerdings "schon" vor der Zeitumstellung im Oktober eingegeben und nun muss ich alle händisch um eine Stunde umstellen.
Für den Sommer hatte ich die Termine per Skript erstellt, weil es über 100 sind, erstellt, und dort gedacht, mein Skript hätte einen Fehler. Mit einem SQL-Skript hatte ich diese dann wieder um eine Stunde korrigiert.

Ich kann Bernd P. zustimmen, dass wenn man Termine vor der Zeitumstellung einträgt, diese nach der Zeitumstellung verschoben sind. An den Serverzeiten oder der Zeitzone wurde nichts geändert.

Allerdings wüsste ich dort auch keine Abhilfe, ausser, dass ich zum Tag der Zeitumstellung ein Skript zur Korrektur laufen lasse.

In Contao 5 konnte ich im Changelog dazu noch keine Änderung finden. Hat jemand diesbezüglich Erfahrung mit Contao 5?

[Spooky]

In Contao 5 hat sich das bisher nicht geändert.