WBCE CMS – Way Better Content Editing.
Du bist nicht angemeldet.
Hallo zusammen,
ich habe festgestellt dass die Zeiteinstellungen nicht übereinstimmen:
Unter GRUNDEINSTELLUNGEN - STANDARDEINSTELLUNGEN- ZEITZONE habe ich "UTC +2 Hours" eingetragen.
Wenn ich aber eine (Test)mail verschicke wird die Zeit 2 Stunden zurückgesetzt.
Unter meinen Benutzereinstellungen habe ich auch UTC + 2Hours stehen.
Die Server Einstellungen unter PHP Info sind auf Europe/Berlin gesetzt was auch richtig ist ;-)
Wo muss ich was umstellen damit die Zeit beim Mail Versand stimmt?
Vielen Dank
Offline
Hallo awuest,
kannst du uns bitte deine WBCE Version nennen?
lg
Offline
Ich kann das so bestätigen (mit der 1.5.1), sowohl lokal als auch auf dem Live-Server.
Zum einen setzt die /framework/Mailer.php
date_default_timezone_set('UTC');zum anderen wird in der /framework/initialize ebenfalls
date_default_timezone_set('UTC');(mit dem Kommentar: @todo this needs to be replaced by a real locale handling)
Wenn ich jetzt in der Mailer.php
date_default_timezone_set('Europe/Berlin');setze "stimmt" die Uhrzeit - bei der Testmail allerdings nur im Email-Header, da die Zeitangaben in der Mail ja noch auf die Einstellung in der initialize.php beruhen.
Ändere ich auch die initialize.php stimmt zwar die Zeitangabe in der Testmail, allerdings bin ich dann in den Grundeinstellungen mit UTC+2 der Zeit 2 Stunden voraus.
Echt tricky das ganze ...
... nein in Europa verwenden wir beim Programmieren nicht € statt $ ...
Offline
@bernd
in der https://github.com/WBCE/WBCE_CMS/blob/m … Mailer.php Zeile 4018
Steht aktuell
date_default_timezone_set(@date_default_timezone_get());kannst du bitte schauen was passiert wenn nur diese Zeile durch folgendes ersetzt wird:
date_default_timezone_set(UTC);Offline
@awuest
damit es bei dir wieder alles passt müsste es reichen die Zeit der User und von WBCE auf UTC zu stellen, dann rechnet WBCE nichts weg oder dazu und verwendet UTC oder die Serverzeit.
Beitrag geändert von colinax (29.10.2021 15:14:34)
Offline
@colinax:
ne, das ändert nix, da ja das date_default_timezone_get ohnehin das UTC der php.ini holt.
Zumindest auf meinen Testsystemen und vermutlich wohl auf allen Servern die einigermaßen Uptodate sind.
... nein in Europa verwenden wir beim Programmieren nicht € statt $ ...
Offline
Per se finde ich es ja nicht wirklich schlimm wenn der Mailer UTC verwendet und dann die "korrekte" UTC-Zeit im Header angibt.
Die Zeit bekommt der "Otto-Normal-Usy" ja eh nicht zu Gesicht.
Denke da brauchen wir nix dran fummeln.
Das eigentliche "Problem" ist IMHO halt, das fixe setzen der default_timezone auf UTC in der initialize.
Das führt letztlich dazu, dass alle Datum-/Zeitangaben die "stumpfsinnig" per date() generiert werden wie z.B. in der send_testmail.php "falsch" sind.
Ersetze ich dort z.B. das
'DATE' => date("d-m-Y"),
'TIME' => date("H:i:s");durch
'DATE' => date("d-m-Y", time() + DEFAULT_TIMEZONE),
'TIME' => date("H:i:s", time() + DEFAULT_TIMEZONE),Stimmt die in der Mail angezeigte Uhrzeit.
Hat aber den Nachteil, das man bei dem dämlichen Sommer-/Winterzeit Geraffel ständig dran denken muss.
IMHO müssten wir wirklich an der initalize.php ansetzen und dort eine korrekte Zeitzone setzen statt dem generischen UTC.
Das gäbe aber eine richtig heftige Ersetzungstabelle, da ja PHP z.B. kein "UTC+2" aktzeptiert, sondern nur die sperrigen Angaben wie "Europe/Berlin" ...
... nein in Europa verwenden wir beim Programmieren nicht € statt $ ...
Offline
Bernd, auch wenn es der User nicht sieht, wenn aber die Zeiten im Header nicht stimmen, könnte es sein, dass so manche Spam-Filter anschlagen.
Das sollte man eventuell berücksichtigen.
Offline
IMHO müssten wir wirklich an der initalize.php ansetzen und dort eine korrekte Zeitzone setzen statt dem generischen UTC.
Das gäbe aber eine richtig heftige Ersetzungstabelle, da ja PHP z.B. kein "UTC+2" akzeptiert, sondern nur die sperrigen Angaben wie "Europe/Berlin" ...
Eine korrekte Zeitzone in der initalize.php funktioniert mit dem aktuellen System nicht dank PHP, da es zwischen gmdate/date, UTC und Europe/Berlin nicht übersetzten kann.
Die einfachste und saubere Lösung ist WBCE auf Servertime umzustellen.
Beitrag geändert von colinax (29.10.2021 11:46:12)
Offline
@berny:
nein, die Uhrzeit im Header stimmt ja an sich, denn sie wird ja korrekt als UTC gekennzeichnet
Date: Thu, 28 Oct 2021 19:17:00 +0000
während sie ja, wenn ich die default_timezone auf "Europe/Berlin" umbiege, auch korrekt als UTC+2 gekennzeichnet wird
Date: Thu, 28 Oct 2021 21:18:00 +0200
... nein in Europa verwenden wir beim Programmieren nicht € statt $ ...
Offline
berny
@colinax:
Die einfachste und saubere Lösung ist WBCE auf Servertime umzustellen ...
Damit ist uns aber auch nicht geholfen, wenn z.B. der Server des deutschen Benutzers in den USA steht ?!?
Blöd gefragt:
woher hast du die Info?
Laut PHP darf date_default_timezone_set nur einmal innerhalb der PHP Umgebung eingesetzt werden und auch nur dann wenn die Zeit nicht stimmt
Beitrag geändert von bernd (28.10.2021 21:28:27)
... nein in Europa verwenden wir beim Programmieren nicht € statt $ ...
Offline
@colinax:
Die einfachste und saubere Lösung ist WBCE auf Servertime umzustellen ...
Damit ist uns aber auch nicht geholfen, wenn z.B. der Server des deutschen Benutzers in den USA steht ?!?
globale php.ini anpassen oder. per .htaccess korrigieren, leider gibt es dafür keine fehlerfreie all-in-one Lösung nur einzelne die nicht kompatible sind außer man verwendet die PHP gesteuerte "Europe/Berlin" Lösung und umgeht die Probleme damit
Blöd gefragt:
woher hast du die Info?Laut PHP darf date_default_timezone_set nur einmal innerhalb der PHP Umgebung eingesetzt werden und auch nur dann wenn die Zeit nicht stimmt
Letztes Jahr gab es innerhalb von PHP einen Fehler mit der Zeitberechnung, die Ursache damals war dass der vergleich von zwei date_default_timezone_set immer true also gleich war (da es keinen gab/gibt). In den Workarounds stand das date_default_timezone eine globale Variable ist, diese soll auch nur einmal definiert werden (oder eben sicherstellen dass alle date_default_timezone_set den gleichen Inhalt haben).
Also nach dem Motto Server-Zeitzone auslesen, speichern und verwenden falls Server-Zeitzone nicht stimmt per DropDown die in php vorhandenen Zeitzonen darstellen lassen, die korrekte wählen, speichern per date_default_timezone_set definieren und verwenden (soweit ich es Verstanden habe)
Offline
So, ich hab mir das nochmal in Ruhe in einer jungfräulichen Installation angeschaut, also ohne weitere Module.
Meine Meinung:
so wie es jetzt ist, das WBCE intern mit UTC arbeitet, ist absolut o.k und funktioniert ja auch eigentlich durchgängig ordentlich.
z.B. bei der Modifikationszeit der Seiten wird ja die "TIMEZONE" (also diese +7200 bei UTC+2) entsprechend berücksichtigt, etc.
Soweit ich das sehe ist die send_testmail.php die einzige Stelle an der die Zeitangabe zu Irritationen führt, da dort nicht korrigierend eingegriffen wird und eben die Zeit in UTC ausgegeben wird.
Mein Vorschlag:
entweder dort die Änderung wie in #7 erwähnt einbauen,
oder mittels
'TIME' => date("H:i:s e"),explizit die verwende Zeitzone (UTC) mit angeben.
Einfach um Verwirrungen zu vermeiden.
Falls es Module geben sollte bei denen der gleiche Effekt auftritt, also eine vermeintlich "falsche" Zeitangabe durch die Verwendung eines "nackigen" date() ohne TIMEZONE Berücksichtigung müsste dann halt in dem betroffenen Modul nachgebessert werden.
Das dürfte einfacher sein als das wir uns jetzt das System "kaputtreparieren" bei dem Versuch eine Eierlegende-Wollmilch-Lösung, die alle wenn und abers abdeckt, einzubauen.
Beitrag geändert von bernd (28.10.2021 23:24:24)
... nein in Europa verwenden wir beim Programmieren nicht € statt $ ...
Offline
Guten morgen, sorry war gestern nicht mehr online.
VIELEN DANK für die tipps, Vorschläge etc..!
Bevor ich etwas "kaputtrepariere", für "OTTONORMALVERBRAUCHER"
:
Wo musste man was ändern damit die Zeitzone jetzt stimmt?
Offline
@all
So weit ich das verstehe, tritt das Problem wirklich NUR bei der Testmail auf, ist das korrekt?
In diesem Falle möchte ich defintiv nicht, dass nur deshalb alles auf Null gesetzt wird und bei Benutzer- und Grundeinstellungen und folglich Seiten, Newsbeiträgen etc. nur noch UTC zur Verfügung steht. Das wäre nun wirklich das Kind mit dem Bade auskippen.
Erstens: wie häufig kommt es vor, dass die Testmailfunktion genutzt wird? Ungefähr null- bis einmal pro WBCE-Instanz.
Zweitens: Selbst wenn diese mit der falschen Zeitangabe versendet werden sollte - und mir scheint diese sowieso nur im Footer IN DER MAIL zu stehen ("Diese Mail wurde um 06:57 versendet") sehe ich nun wirklich nicht, inwieweit dadurch irgendwelche (Spam-)Probleme entstehen könnten.
Kurz gesagt: es ist schön, dass Ihr Euch da so einen Kopf darum macht, aber ich glaube, hier wird definitiv mit Kanonen auf Spatzen geschossen.
Offline
Danke Florian
Bei der Bestätigungsmail die man bei der Registrierung (Freischalten) eines neuen "Kunden" bekommt , tritt das Problem auch auf.
Zu finden unter:
new_user_manager_info.txt.php unter Anmeldedatum: {{SIGNUP_DATE}} (falls dies hilft)
Offline
Bei der Bestätigungsmail die man bei der Registrierung (Freischalten) eines neuen "Kunden" bekommt , tritt das Problem auch auf.
Zu finden unter: new_user_manager_info.txt.php unter Anmeldedatum: {{SIGNUP_DATE}} (falls dies hilft)
Danke für die Info.
Ich hab mir den Accountbereich mal angesehen, sofern der Accountbereich nicht einen Wert bekommt der schon lokalisiert ist arbeitet diese ohne der Zeitzonen Korrektur.
Kannst du bitte mal so wie in #5 geschildert einstellen und schauen, wie es sich bei dir dann verhält, dann kann ich auch sagen, wo der Fehler liegt.
@all
So weit ich das verstehe, tritt das Problem wirklich NUR bei der Testmail auf, ist das korrekt?
Soweit ich es sehe, ist überall wo es den User nicht optisch betrifft, bei komplett neu geschriebenen Code (Accountbereich, phpmailer (andere hab ich noch nicht überprüft) auf die Zeitkorrektur verzichtet worden
In diesem Falle möchte ich defintiv nicht, dass nur deshalb alles auf Null gesetzt wird und bei Benutzer- und Grundeinstellungen und folglich Seiten, Newsbeiträgen etc. nur noch UTC zur Verfügung steht. Das wäre nun wirklich das Kind mit dem Bade auskippen.
Das hast du falsch verstanden, das mit der 0 ist ein Workaround damit wir keinen Code brechen, wenn wir auf Servertime umstellen
Offline
Habe jetzt unter user (ich als admin) die Zeitzone auf UTC engestellt: es werden 2 Std. zurückgerechnet (10:20 statt 12:20)
Das gleiche auch unter Grundeinstellungen, Testmail
Offline
Dass heißt dass jetzt die Uhrzeit in der Testmail mit der WBCE eingestellten Uhrzeit übereinstimmt oder?
Offline
So ist es jetzt:
Meine Daten: Zeitzone: UTC 10:50
Grundeinstellungen: Zeitzone UTC 10:50
Test-mail: 10:50
Wenn ich jetzt unter
Grundeinstellungen Zeitzone UTC +2 ändere habe ich die RICHTIGE Uhrzeit (12:50)
Testmail BLEIBT auf 10:50
Wenn ich keine Änderungen unter Meine DAten mache (also kein UTC +2, habe ich die falsche Uhrzeit auch beim erstellen neuer Seiten
Also ändere ich jetzt wieder auf UTC +2: AUF die MAil Funktion hat dies keine Wirkung (bleibt auf - 2 Stunden also UTC)
DAnke für deine Mühe
Offline
so wie ich das sehe werden die server einstellungen von sendmail (php) ignoriert
Offline
So ist es jetzt:
Meine Daten: Zeitzone: UTC 10:50
Grundeinstellungen: Zeitzone UTC 10:50
Test-mail: 10:50Wenn ich jetzt unter
Grundeinstellungen Zeitzone UTC +2 ändere habe ich die richtige Uhrzeit (12:50)
Testmail bleibt auf 10:50
Wenn ich keine Änderungen unter Meine Daten mache (also kein UTC +2, habe ich die falsche Uhrzeit auch beim erstellen neuer Seiten
Also ändere ich jetzt wieder auf UTC +2: AUF die Mail Funktion hat dies keine Wirkung (bleibt auf - 2 Stunden also UTC)
so wie ich das sehe werden die server einstellungen von sendmail (php) ignoriert
Dann weis ich schon was los ist.
Dein Server hat als Zeitzone Europe/Berlin, da WBCE UTC benötigt wird es per date_default_timezone_set('UTC') erfolgreich auf UTC gestellt, soweit so gut.
Unser Problem dass hier zugrunde liegt ist, dass bestimmte Core Teile anders mit der Zeit umgehen. Bei den Modulen ist es das Gleiche Errorlogger und wbstats rechnen auch ohne Zeitzonenversatz
@Bernd
könntest du uns über Linux eine Auflistung geben in welchen Dateien eine "date(" also die php date Funktion vorkommt?
Offline
@colinax:
ist bischen schwer zu differenzieren, weil ein grep auf "date(" halt auch alle Vorkomnisse von "date(" in Javascript mit erfasst (und das sind nicht wenige) ....
... nein in Europa verwenden wir beim Programmieren nicht € statt $ ...
Offline
@colinax:
ist bischen schwer zu differenzieren, weil ein grep auf "date(" halt auch alle Vorkomnisse von "date(" in Javascript mit erfasst (und das sind nicht wenige) ....
hast du Excel zur Verfügung?
Da lässt sich das easy per "bedingte Formatierung" erledigen.
Sonst schick mir die Datei, dann schau ich mir das an
Offline
Anbei die Dateiliste ohne .js Dateien. Ist auf den ersten Blick bischen viel.
Interessant sind ja wirklich nur die Vorkommnisse bei denen eine date() Ausgabe erzeugt wird ohne die TIMEZONE zu berücksichtigen und das dürften nicht allzuviele sein ...
Ich würde ja selber danach schauen, hab aber grade noch ein anderes dickes Problem an der Backe, das dringend zuerst gelöst werden muss.
... nein in Europa verwenden wir beim Programmieren nicht € statt $ ...
Offline