Überraschende Wende: Rückkehr zur Winterzeit MORGEN!

Sei still! Das sag nicht nur ich, sondern auch die Nationale Stillkommission in Karlsruhe.

Mir gefällt das, denn ich habe seit der Serverumstellung und PHP 8 ein gewaltiges Zeitenproblem. Irgendwie macht die Datenbank Zulu, PHP eine Mischung aus Zulu und Zeitzone und PHPMA besteht auf "Sommerzeit". Super. Alles, was irgendwie regelmäßig stündlich stattfinden soll, geht nun nicht mehr, da die Zeiten nun 2 Stunden auseinander liegen.

Ich trage also einen neuen Datensatz in die DB ein, der erhält dann automatisch durch datetime() z.B. 08:03 als Zeitstempel. Das ist aber 08:03 Sommerzeit. PHP ruft dann ab und prüft, ob älter als eine Stunde. Jo, für PHP ist das 08:03 aber Zulu, also intern ist es da dann 10:03. Und nein, jetzt in Bezug auf die Zeit ist dann eben nicht eine Stunde. Sprich, das Script, das eigentlich um 09:03 wieder laufen müsste, läuft nicht, weil intern ist es ja 10:03. Verflucht noch mal. Hab da nun schon einiges geändert und angepasst, aber es will einfach nicht richtig.

Und ich frage mich wirklich, warum so eine Änderung an PHP 8 nicht im Changelog als Breaking-Changes hinterlegt ist.

Die "Default timezone" war in PHP immer die vom OS. Nun ist das nicht mehr so und default "UTC". Sämtliche date()- und time()-Funktionen liefern falsche Werte. Dann hab ich das schon manuell geändert auf "Default timezone = Europe/Berlin", was aber irgendwie auch nicht wirklich funktioniert, wie ich heute merken musste

Zitat von Synonym

Mir gefällt das, denn ich habe seit der Serverumstellung und PHP 8 ein gewaltiges Zeitenproblem. Irgendwie macht die Datenbank Zulu, PHP eine Mischung aus Zulu und Zeitzone und PHPMA besteht auf "Sommerzeit". Super. Alles, was irgendwie regelmäßig stündlich stattfinden soll, geht nun nicht mehr, da die Zeiten nun 2 Stunden auseinander liegen.

Speicherst du die Zeitzone mit, bzw. Gibst du sie mit an wenn du die Zeitdifferenz berechnest? Ansonsten nutzt dein Server wohl GMT, aber nicht die Berliner Sommer/Winterzeit.

Lass mich ausholen.

Mein Server nutzt GMT, das ist korrekt. Er nutzt aber auch die Sommerzeit, also automatische Zeitumstellung.

Der Server ist also genauso wie jeder andere Server mit PHP 7.4 auch.

Nun mit PHP8 ist es aber so, dass der Wert "default timezone" eben leer ist. Gut, war er vorher auch, aber da hatte PHP dann ja automatisch den Wert vom OS genommen. Also entweder globale ini, oder user.ini oder eben OS. Letzteres ist nun nicht mehr der Fall. PHP nimmt als default, denn leer ist auch default, immer UTC.

In den meisten Fällen speichere ich die Daten einfach als Uhrzeit oder eben als Datetime in der DB, also als "07:47:56" oder eben als "2024-04-03 07:47:56". Also auch so wie immer. Zeitzonen werden nicht gespeichert, da für das Vorhaben nicht relevant.

Speichere ich hier z.B. bei PHPMyadmin einen neuen Datensatz, der now() als default hat auf einer Zelle oder eben "on Update", dann ist das die aktuelle Zeit, also "07:47:56". Steht so auch in der DB. Rufe ich das ab und gebe es mit PHP aus (date()-Funktionen), das steht das auch korrekt auf der Seite.

An manchen Stellen passiert es aber, da wurde ich noch nicht ganz schlau draus, dass PHP dann mit dem Datum rechnen muss und der Meinung ist, dieses 07:47:56 wäre UTC. In der Berechnung meint PHP dann also, das wäre 09:47:56.

Und da gibt es dann eben ganz simple Funktionen wie "wenn kleiner als "now()", dann mache X, ansonsten überspringe". Nachdem das aber eben in der Berechnung dann "09:47" ist, läuft er ins "überspringe".

Selbiges Verhalten auch mit File-Opreationen. Habe da einen normalen Cache, der auf Create-Time beruht. Älter als 90 Minuten, soll neu erstellt, ansonsten eben das Temp-File genommen werden. Auch da hackt es, denn irgendwie sind die Files alle "outdated", obwohl gerade erst neu angelegt.

Und, PHP8 war auch nicht ganz richtig. Wenn ich das richtig gelesen habe, gibt ja noch andere mit dem Problem, dann ist das wohl seit PHP 8.2 so.

Stelle ich den Server auf UTC um, dann arbeitet alles ganz normal. Das ist aber doof. Ich hätte gerne deutsche Zeiten in den Logs stehen etc und vor allem importiere ich auch viele Daten, die Zeiten enthalten und da steht auch keine Zeitzone dabei. Default ist da aber überall "Berlin".

Wie berechnest du denn das datum?

Hast du in deinem projekt irgendwo global
date_default_timezone_set('Europe/Berlin'); 
gesetzt um sichgerzugehen das dein system bescheid weiss?

Ich benutzte Laravel, was die Carbon datetime libary hat. Finde ich intuitiver damit zu arbeiten, as die standard PHP funktionen.
Damit dann eben:

$dt_created = Carbon::parse('2024-04-03 12:00:00', 'Europe/Berlin');
$dt_now = Carbon::now('Europe/Berlin');

und dann damit dann eben vergleichen ob abgelaufen, gueltig oder wieviel zeit noch bleibt.

Ich hatte nur vor kurzem damit zu tun, da die seite eintraege in der zeitzone des nutzers seichern muss, die dann zu einer bestimmten zeit in der selben zeitzone(!) wieder entfernt werden muessen. Das problem war eben, das die seite nutzer in australien, europa und nordamerika hat und dementsprechend zeitzonen und servertime beruecksichtigt werden mussten.

Das habe ich nun in der Ini gesetzt. Also PHP weiß das eigentlich schon.

Wenn ich mir die phpinfo nun ansehe, dann schaut die quasi so aus wie die von php 7.4, nur eben, dass ich nun bei Timezone einen Wert habe. Vorher und default ist ja "leer", also vorher "OS".

Ein "date_default_timezone_get()" liefert auch den korrekten Wert.

Das mit den Nutzern weltweit habe ich auch, aber ich mache es dennoch ohne Zeitzonen, denn es gibt in den wichtigen Bereichen nur zwei Zeiten. 13 und 14 Uhr. Da ist das quasi egal, wer in welcher Zeitzone ist. In den Berechnungen geht das in dem Fall auch nicht ein. Dieses 13 und 14 Uhr markiert quasi nur Ende und Start an einem Tag.

Bei PHP heißt es nur sinngemäß, dass man date / time als Funktion nicht mehr nutzen sollte oder die gm-Funktionen, sondern stattdessen die Date-Klasse nehmen soll und dort dann mit "DateTimeImmutable".

Der Rest, also Cache und so oder eben Interval-Abruf, der braucht nur einen bestimmten zeitlichen Abstand. Zeitzonen sind da auch egal. Also z.B. +1 Stunde eben, egal welche Zone. Das Problem ist ja da irgendwie, dass das Datum in der DB, also das, wie es in Deutsch sein sollte, nicht wirklich das ist, was ich errechne mit time() oder mktime() + 3600 oder date +1 Day. Wie gesagt, ich raffe es noch nicht ganz, es geht an vielen Stellen, aber an einigen nicht.

Mein lieber Alex, Winterzeit ginge hier gar nicht, dann wäre es morgens um 9 noch stockdunkel, auch, wenn die Tage jetzt wieder länger werden.

Im Moment hätten wir, nach Winterzeit, Beginn Sonnenaufgang um 9 Uhr 05.

Zitat von Synonym

Das Problem ist ja da irgendwie, dass das Datum in der DB, also das, wie es in Deutsch sein sollte, nicht wirklich das ist, was ich errechne mit time() oder mktime() + 3600 oder date +1 Day. Wie gesagt, ich raffe es noch nicht ganz, es geht an vielen Stellen, aber an einigen nicht.

Ja zeig doch Mal den relevanten Code der das falsche Datum liefert.

Mit hardcodierten werten ein Datum zu berechnen ist ganz schlecht, da verschiedene Zeitzonen teilweise an verschiedenen Tagen Zeitumstellung haben. Soll heißen meistens ist der unterschied dann z.b. 1h, aber zwischen der Zeitumstellung in den beiden Regionen kann es auch ein paar Wochen geben in welchen der unterschied dann eben 2 oder 0 Stunden ist.

In Australien wird Zeitumstellung auf Landesebene geregelt, womit einige Länder Sommerzeit haben und andere nicht, oder die Zeitdifferenz zum Nachbarstaat ist 30 Minuten statt 1h.

Na, das mit den Zeitzonen ist kein Problem, echt nicht. Das 13 und 14 Uhr war auch nur ein fiktiver Wert, der eigentlich so von allen genommen wird. Andere nehmen auch 10 und 14 Uhr oder so. Es geht da um An- und Abreisen. Im Grunde geht es hier nur um ein Datum, also z.B. "2024-04-04" und "2024-04-04"- Das hat halt eine Zeit dabei, damit klar wird, was davon die Abreise und was die Anreise ist. Abreise ist früher, Anreise später. Klar, es kann in ganz entfernten Ländern Probleme geben, das ist technisch möglich. Aber mit den Werten ist es so, dass 99,999999% aller Nutzer kein Problem haben, denn es wird sich durch die verschiedenen Zeitzonen kein Tag an sich ändern. Zielgruppe ist ja primär Europa bzw. eben was in den Zeitzonen -0500 bis +0500.

Wegen den anderen Dingen, da wo Zeiten benutzt werden, die sind nur in DE bzw. eben alle an einem Ort.

Code ist nun stark minimiert, aber nichts Besonderes.

$update_interval = 3600-10;

// -10 Sek, weil der Scriptdurchlauf ein paar Sekunden braucht und der Cron nur im Minutentakt läuft. Der Abstand ist also eine Stunde oder ein paar Sekunden weniger, aber niemals mehr. Würde sich sonst aufschaukeln und jede Stunde mehr werden. Scriptsurchlauf ist ca. 2-5 Sekunden.

$sql = 'SELECT x FROM y AS blki WHERE blki.aktiv = 1 AND blki.next_import < now() LIMIT 25';

// Next_import ist schon ein Wert in der DB, der als +1 Stunde gespeichert wird. Daher einfach der Vergleich, ob der gespeicherte Wert kleiner als der aktuelle Wert ist. Wenn ja, dann ist der Eintrag älter als eine Stunde.

Dann erfolgt die Verarbeitung der Daten, die von extern kamen. Haben aber mit den eigentlichen Zeiten nichts zu tun. Da kommt nur das mit An- und Abreise zu tragen bzw. werden die Daten aufbereitet.

$next_import = date('Y-m-d H:i:s', time()+$update_interval);

$sql = 'UPDATE y SET last_import = \''.$date_last_import.'\', error_count = 0';
if($date_last_modified !== false) $sql .= ', last_modified = \''.$date_last_modified.'\'';
$sql .= ', next_import = \''.$next_import.'\' WHERE uk_id = '.$import['uk_id'];

So, und da ist dann eigentlich auch das Problem. Nicht immer, aber manchmal. Genau suchen konnte ich noch nicht.

Wenn ich also einen Datensatz manuell in der DB eintrage, dann ist "next_import" z.B. aktuell "08:14:22", eben "jetzt" + eine Stunde Intervall. Das sollte dann ja die erste Query erfassen und abfragen. In einer Stunde ab jetzt würde der dann fällig und müsste selektiert werden. Ist aber eben nicht der Fall. Selektiert wird er quasi erst in 3 Stunden. Also die reguläre +1 Stunde und eben die +2 Stunden Sommerzeit.

Beim Update dann wird es wieder seltsam, denn dann geht das GMT / UTC-Spiel wohl umgedreht. Sprich. Wenn der dann endlich mal selectiert hat und dann am Ende das "next_import als neuen Wert in die DB schreibt (updatet), dann ist das keine GMT-Zeit mehr, sondern UTC. Der schreibt dann also kein "10:14:22" rein, was eben dann rechnerisch sein müsste, sondern dann UTC "08:14:22". Also jede Zeit dann entsprechend abzüglich Winter- oder Sommerzeit, rein UTC eben. Und beim nächsten Durchlauf wird dann sofort selectiert, weil "next_update" nicht mehr eine Stunde in der Zukunft ist. Steht dann ja "08:14" in der DB, obwohl in echt schon "10:14" ist.

Also völlig wirr. Erst wird der Zeit +2 Stunden Sommerzeit hinzugerechnet, beim ersten Durchlauf und dann bei jedem weiteren wird jeweils +2 Stunden abgezogen und in die DB geschrieben. Was dazu führt, dass eben der erste Import viel zu spät kommt und dann bei den folgenden keine Pause von einer Stunde. Sondern die gleichen immer wieder jede Minute kommen. Was sinnlos ist, denn es sind ja immer die selben, limitiert mit dem "Limit 25" in der Query. Eigentlich ist die Zeitsperre ja da, damit der an die 900 Importe pro Stunde fährt und dann eben, eine Stunde später, wieder alle durcharbeitet. Jeder Import soll einmal pro Stunde laufen.

Das funktioniert auch alles seit 15 Jahren. Nur eben nicht mehr richtig, seit dem Notumstieg auf einen neuen Server mit PHP 8.2

Das script sieht ja schon ziehmlich "rustikal" aus mit seinen zusammengefrickelten SQL queries die nur auf eine SQL-injection warten.

Allerdings nutzt du hier gleichzeitig Mysql NOW() und die PHP zeitfunktionen. Laeuft MySQL auf dem selben server, oder einem anderen? Weisst du genau, welche zeitzone MySQL verwendet?

Hier kannst du die aktuellen MySQL einstellungen sehen:

SELECT TIMEDIFF(NOW(), UTC_TIMESTAMP) AS timezone_offset,
DATE_FORMAT(NOW(), '%Z') AS timezone_name;

Ich selbst versuche MySQL NOW() zu vermeiden, und nutze stattdessen den PHP wert - z.b. date('Y-m-d 00:00:00'). Damit gibt es nur eine referenzzeit, und ausserdem koennen select-abfragen mit den MySQL datumsbefehlen nicht gecacht werden, da diese nicht wiederholbar sind. Wenn du allerdings die abfrage als "SELECT ... WHERE created_at >= '2024-04-05'" mit festem datum an mysql schickst, dann wird das ergebniss gecacht und ist damit prinziell schneller.

Hi, Danke Dir, auch wegen den Warnungen. Aber ich kann Dich beruhigen, SQL-Injections sind nicht möglich. Wie gesagt, das ist nur ein kleiner, relevanter Auszug. Die Daten sind alle mehrfach geprüft, werden vom Script selbst erzeugt und wenige Zeilen vor der jeweiligen Query überhaupt erst gesetzt. Mit dem Now und dem Cache hast Du recht. Mache ich normalerweise auch nicht so, sondern so wie Du. Ist hier aber egal, denn der Durchlauf ist eh nur einmal minütlich und da wäre es dann auch per PHP und direktem Date ohne Cache, da jede Minute eine neue Uhrzeit Der Vorteil so, es lässt sich leichter Debuggen, wenn man sich die Querys ausgeben lässt, dann steht da nämlich schlicht das Mysql-NOW und nicht irgendein Zeitstempel.

Datenbank, PHP, Webserver, alles, ist auf der gleichen Maschine. Da ist auch nur die eine Domain drauf.

Deine Mysql-Query scheint nicht ganz zu stimmen bzw. ist zu "neu". %Z kennt mein MariaDB nicht. Er gibt daher keinen Zeitzonennamen aus, sondern einfach "Z". %Z gibt es erst ab Version 11.3, ich habe hier 10.11, vorher 10.8

Aber ja, MariaDB ist korrekt, kennt den Offset von aktuell 2 Stunden.