Beiträge von Synonym

Ah, ok. Was ist aber eigentlich "uSv"? Universelle Stromversorgung oder was? Steht da ständig auf der Seite und auch noch "pro Stunde". Wenn Mikrosievert gemeint ist, dann sollte man auch Mikro schreiben, also "μSv".

Und was genau hat es mit den "0.12" aufsich? Warum dieser Grenzwert und kein anderer? Wird nirgends erwähnt, da steht nur "0 bis 0,3 µSv/h" als Erklärung. Nachdem das aber so extrem auffallend rot geschrieben ist, muss da ja wichtig sein und da es sehr häufig vorkommt, sollte man wohl von Bertingen fernbleiben, oder?

Und was ist CPM? Soll das "Cost-per-Mille" sein?

Na, die Seite ist so ganz ohne Bilder. Mach doch mal welche von Deinen Messeinrichtungen, damit man die auch sehen kann bzw. weiß, welche Geräte die Daten da so liefern. Sollte ja nicht so schwer sein, seine Wetterstation etc. zu fotografieren, wie sie da auf dem Mast hängt oder auf dem Dach steht. Interessant wäre natürlich auch, wo die denn stehen. Auf dem Campingplatz? In der Ortsmitte? An der Straße? Auf dem Dach der Feuerwehr? Mitten im Feld?

Was ich eigentlich erwarte.... Alle Rechnungen stornieren. Dieses fehlerhafte System stoppen. Alles was schon abgebucht wurde dem Konto gutschreiben. Alle Rechnungen und Laufzeiten etc manuell prüfen und korrigieren. Dann eine neue Rechnung erstellen und mit dem Kundenkonto verrechnen. Den Restbetrag mir erstatten.

Das versuche ich lieber nicht, das ist schon Choas genug. Mittlerweile hat sich ein echter Mitarbeiter gemeldet, aber nur damit, dass das "Script" nun läuft und alles korrigiert wird.

Dann meldete sich 2 Stunden später wieder die AI plötzlich zu Wort.

Anschließend wurden zwei Rechnungen storniert, zwei von 8. Bezahlt waren sie schon.

Weitere zwei Stunden später kamen 3 neue Rechnungen, welche, die es vorher noch nicht gab und auch diese sind komplett falsch.

Habe da gerade ein Problem mit einem Unternehmen, das mir völlig falsche Rechnungen ausstellt, also falscher Betrag, falscher Leistungszeitraum und dann dazu auch noch andere Summen vom Konto abbucht, als in den falschen Rechnungen stehen.

Super ist das. Da blickt ehe schon keiner mehr durch.

Schreibe da nun schon 8 Tickets und bekomme immer wieder ein "tut uns leid, ist gerade viel los, es dauert noch etwas, hinterlassen sie mehr Details, damit es schneller geht"

Auch super, Details waren schon mehr als genug genannt. Alles geht nicht, da müsste man ein Buch schreiben und wäre Wochen beschäftigt, stimmt ja schließlich gar nichts und das rückwirkend bis ist Jahr 2022.

Das so in etwa geschrieben und nun eine andere Antwort bekommen, von Arisa. Die sagte mir aber auch nicht viel. Dann in der Signatur gefunden:

"Please note: This is an AI-generated response and is part of our experimental feature to improve customer service efficiency. Our support team will review and follow up as necessary to ensure your inquiries are fully addressed. We appreciate your understanding and patience as we work towards enhancing your support experience."

https://www.seroundtable.com/google-search-…ency-37658.html

Man kann es sich ja noch anzeigen lassen....

Einfach auf Suchfilter klicken, dann stehen die Daten rechts oben. Was das aber mit einem Suchfilter zu tun hat, weiß wohl selbst Google nicht. Geht aber nur mit "Suchfilter". Wenn der Punkt "Suchoptionen" heißt, was auch manchmal vorkommt, dann geht es nicht.

Naja, die Verweildauer gehört auch zu SEO. Genau genommen müsste man erst mal definieren, was SEO überhaupt ist, denn letztendlich ist das auch was wie, welche Schriftfarbe nutzt man.

Ich bezweifle aber, dass die Verweildauer einen sonderlich großen Einfluss hat, auch wenn das immer wieder behauptet wird. Das ist halt typisch SEO. Es wird immer gesagt, wiederholt, von anderen gesagt etc, aber keiner kann einen Beweis oder Beleg vorlegen.

Ich bezweifle es aus schlicht technischen Gründen, denn wie soll Google die berechnen? Du hast den Tagmanager drauf, ok, der kann Zugriff und Absprung erkennen. Google behauptet aber, dass die Daten nicht fürs Raning benutzt werden. Andere haben Adsense drauf, auch da könnte man das erkennen, aber auch hier angeblich nicht benutzt,

Was unumstritten ist ist, die Zugriffe über die Suche und die Rückkehr zu ihr. Nur das ist ja alles andere als zuverlässig. Was ist denn, wenn man aus den Suchergebnissen 3 Seiten öffnet, zeitgleich, im neuen Tab? Wie lange war man nun auf einer Seite? Für Google nicht messbar. Oder wenn man eine Seite öffnet, die grottenschlecht ist, aber man erst mal einen Kaffee tringt, bevor man auf den "zurück-Button" klickt?

Oder, nimm als Beispiel eine Seite, die schlicht, einfach und sehr übersichtlich ist. Nach 20 Sekunden hast Du gefunden, was Du wissen willst. Dann nimm eine andere, bei der suchst Du 2 Minuten in den Untiefen, bist frustriert und hast dennoch nicht das gefunden, was Du wolltest. Welche ist nun besser? Die mit den 20 Sekunden oder die mit den 2 Minuten Verweildauer? Die Länge kann also nicht wirklich viel aussagen.

Das Einzige, wie Google es recht zuverlässig messen kann ist Lighthouse, also über alle User, die Chrome benutzen, denn das sendet ja Daten an Google. Das sind eben dort in der Auswertung die "Feld-Daten". Das sind Daten, die nicht rein statistisch ausgewertet wurden, sondern individuell für jeden Besucher auf der Seite. Feld-Daten haben aber nur Seiten, die auch recht viele Besucher haben. Je weniger, desto ungenauer.

Ich habe hier z.B. eine Domain, die hat eine durchschnittliche Verweildauer von 13 Sekunden. Das ist eine der besten Seiten, die ich habe, in Sinne vom Ranking. Eine andere hat eine Dauer von durchschnittlich 2 Minuten und ist im Ranking eher auf den Plätzen 50 bis 100.

Meiner Meinung nach kann man die ganzen SEO-Tools in die Tonne kloppen. Die sind vielleicht brauchbar, wenn man seine eigene Domain vergleichen will, aber für fremde wird das kompliziert. Zahlen und Grafiken, schön, bunt, übersichtlich, aber was genau sagt das aus?

Schönes Beispiel ja Deine beiden Bilder. Wenn man nach der Länge der Balken geht, müsste zweite Domain ja viel schlechter sein. Also stellt sich berechtigterweise die Frage, was da genau ausgewertet wird und ob das überhaupt eine Relevanz hat. Und wenn es eine hat, wie viel dann aus Sicht von Google. Ich meine, diese 100% bei den Tools kann auch nur ein Faktor mit 1% von den vielen bei Google sein.

Wennste Dich mal in meinem Bereich (Unterkünfte / Reise) umschaust, dann wirst Du bemerken, dass die Big-Player ganz vorne, TFW, Booking, AirbnB und Co alle Seiten haben, die eigentlich gegen alles verstoßen, was Google so vorschreibt. In den Tools können die froh sein, wenn die auf 10 Punkte oder 10% kommen. Ladezeiten von teils über 10 Sekunden etc. Ist das wichtig? Wohl nicht wirklich, denn sie stehen ja allesamt in den Top10. Also wichtig wohl schon, aber nicht mit dem Gewicht, was diese Tools da suggerieren.

Und Dein Mitbewerber.... Das steht ja nicht in der Grafik. Wie viele Links hat der denn? Von welchen Seiten? Wie viele Links haben die jeweiligen Seiten? Wie alt ist die Seite und die Linkseite? Was hat die für Content? Diese Tools zählen, wenn überhaupt, nur Wörter auf der Seite, aber ob das sinnvoll ist oder "Lorem ipsum" wissen die nicht.

"Metaangaben" steht da in der Grafik. 100 und 80%, Was sollen das denn für Metaangaben sein, die da ausgewertet werden? Wichtig ist NUR ein unique Title pro Seite. Bei der Länge geht es schon los. Da gibt es Richtwerte, aber die sind bei Desktop und Mobil unterschiedlich und kommen nicht auf die Anzahl der Zeichen, sondern der Laufweite der Buchstaben an und welche Schrift verwendet wird, also auch die Laufweite beeinflusst, entscheidet Google. Also kann man die so gar nicht beziffern. Alle anderen Angaben in den Meta sind nutzlos. Ok, robots könnte noch was sein, wenn man da falsche Daten setzt.

Server 0%. Wie schlecht muss ein Server denn sein, dass man 0% erreichen kann? Das bedeutet ja eigentlich "nicht erreichbar", offline, Stecker gezogen.

Seitenqualität. Was genau ist das? Wer oder was entscheidet, ob eine Seite oder ein Buch gut oder schlecht ist? Kommt das nicht auf den Betrachter an, der drauf ist oder sich das Buch kauft?

Als Tools, so einfach nutzbar, mit wenigsten ein paar handfesten Hinweisen, auf was sich deren Berechnung der Rangpunkte beziehen ist Lighthouse. Entweder hier https://pagespeed.web.dev/ oder eben im Chrome in der DEV-Console. Wobei es bei denen aber eher um Ladezeit, Usability, Technik geht. Aber auch hier wirst Du merken, dass meine oben erwähnten Reise-Mitbewerber auch grottenschlecht abschneiden, aber dennoch auf Platz 1 stehen.

Das sehe ich schon bald ein Jahr nicht mehr.

Zitat von Hans60

Ich kann dir dann ja mal den Bog ( oder was auch immer) mit teilen. Dann kann ich mich immer noch entscheiden. Danke.

Wäre schön Das Problem bei "Seedingup" ist ja, dass man leider vorher nicht sieht, was da an Linkplatz angeboten wird. Das ist genau der Grund, warum ich da bisher nie was kaufte. Kaufe doch keine Katze im Sack. Und wenn die schreiben, Linkthema XY, dann bedeutet das ja nicht, dass die Domain sich mit dem Thema beschäftigt, das kann ja auch nur eine einzige Unterseite sein und alles andere ist eben was völlig anderes.

Ansonsten ist Link kaufen oder verkaufen immer so ein Thema. Die Frage ist da erst mal, was möchte man erreichen. So was wie "die Leute springen nach Sekunden wieder ab" bemerkt Google gar nicht. Der Link bringt dann vielleicht was für SEO, aber nicht für Verkäufe. Man kann aber eben auch anders kaufen und verkaufen, eben für Besucher und nicht für SEO und schon ist das auch alles völlig legal.

Zitat von Alex07

Du kannst deine Texte mit Copyscape testen, also das die wirklich unique sind. Dann gibt es auch keinen Ärger mit Abmahnungen und Anwalt.

Mit solchen Aussagen wäre ich vorsichtig.

Man kann einen Text durchaus so umschreiben lassen, dass den Copyscape nicht mehr erkennt. Da reicht es schon aus, ein paar Wörter immer wieder zu ersetzen, die Tönalität zu ändern, die Anrede und eben von z.B. aktiv auf passiv zu wechseln, oder umgedreht. Der Text ist dann aber immer noch inhaltlich identisch, nur anders geschrieben. Ob das dann "keine Probleme mit einem Anwalt gibt", darf bezweifelt werden. Wäre ansonsten ja einfach, ein Buch umschreiben zu lassen, das exakt die gleiche Handlung hat, aber anders geschrieben ist.

Ich für meinen Fall lasse auch Text umschreiben, ganze Texte, aber nur meine eigenen. Mit fremden mache ich das anders. Da lasse ich mir erst eine Art "groben Inhalt der wichtigsten Daten" erstellen, das von mehreren Texten. Die werden dann kombiniert. Dann kommen noch eigene Daten dazu, was bisher nicht drinnen war oder eben Zeug, das ich nicht brauche, raus. Dann habe ich eine Art grobe Gliederung für einen Text, die im Grunde auf fremden Texten beruht und eigenen Änderungen. Aus der lasse ich dann einen neuen Text machen. Ich erstelle also nicht einen Text aus einem Text, sondern einen Text aus Stichpunkten. In dem Fall schreibt die KI dann viel freier im eigenen Stil oder eben mit "eigenem Wissen" und nicht auf Basis des Originals.

Bedeutet also, das ist vorab "viel" Handarbeit zur Erstellung der groben Struktur und der Stichpunkte, auch wenn mit KI-Unterstützung. Der Schreibvorgang ist dann rein KI, dann letztendlich noch mal mehrfach lesen und manuell hier und da neu schreiben. Es soll aber auch Leute geben, die das einfach mit der API machen und fertig, was dann aber natürlich alles andere als "unique" wird. Unique im Sinne von Wort- und Buchstabenreihen sind anders, inhaltlich aber nicht.

Naja, das kann täuschen oder kommt auf die Sichtweise an. Aber ja, fern ab von meinen eigenen Seiten und SEO finde ich auch, dass da, wenn man was spezielles sucht, nur noch Mist kommt. Und die Funktion "andere fragten auch", führt noch zu mehr Schwachsinn.

Alleine so was wie "auf glasvlies tapezieren" oder eben "glasvlies übertapezieren". Sollte ja nicht so schwer sein. Was bringt Google??? Wie man Glasvlies tapeziert, also das Vlies selbst. Schon mal völliger Schwachsinn, denn das klebt man und tapeziert es nicht. Oder eben, wie man Vliestapete tapeziert. Auch super. Ich will aber, wie man AUF Glasvlies tapeziert.

Und in anderen Bereichen genauso. Es kommt hier irgendwie nur noch Schmarrn oder eben Shopping.

Ach ja, das Update ist seit dem 19.4. fertig. Hat alle Domänen von mir erwischt, bis auf eine. Die war die ganze Zeit stabil. Die hat es dafür danach erwischt, also zwischen dem 22. und 26.4.

Da ist das BSI schön langsam. Ist doch schon knapp eine Woche bekannt. Betroffen sind quasi keine aktuellen Distros. Nur in Sonderfällen, wenn was anderes benutzt wird, das darauf zurückgreift.

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.

Also wegen Brave. Da scheint es wohl auch andere zu betreffen.

https://community.brave.com/t/brave-browse…ell-help/541301

Und eben auch Youtube

https://community.brave.com/t/aggregate-to…tube/541251/176

Bei mir versucht, da geht alles. Version 1.64.116 auf Win10.

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 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.

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".

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