WebsiteBaker Community Forum
WebsiteBaker Support (2.12.x) => General Help & Support => Topic started by: Concilla on January 26, 2019, 01:20:30 PM
-
Hallo Websitebakerer,
ich habe eine Frage zum E-Mail-Versand Formular bzw. bitte hier um Hilfe.
Seit geraumer Zeit habe ich im Kontaktformular schon Checkbox für die Datenschutzerklärun g mit eigenem Text, Verlinkung und E-Mail-Widerruf. Diesen wollte ich gern so beibehalten. Also, schalte ich für das Formular unter Optionen nach einem Update von WB auf 2.12.1 die Datenschutzrichtlin ie aus.
In der versendeten Mail erscheint nun der Text: „Zustimmung zur Datenschutzrichtlin ie ist deaktiviert“. Was natürlich für den Benutzer sehr verwirrend ist, da die diese separat in der Mail noch einmal auftaucht (siehe oben, Änderung mit Checkbox). Wo kann ich diese Satz aus der zu versendenden Mail entfernen?
Vielen Dank im Voraus.
-
Grundsätzlich muß im Ernstfall die Zustimmung zur Datenschutzrichlini e auch nachgewiesen werden können. Das geschieht durch die gespeicherte Zustimmung in der Datenbank bei Aktivierung der entsprechenden Felder (hier die Checkbox zur DVSGO) im Formular, allerdings nur, wenn man den Originalcode des Moduls verwendet. Die Rechtssprechung geht davon aus, das dieser gespeicherte Wert in der Datenbank korrekt ist, weil dieser Wert ja auch dem Formularbenutzer und dem Admin in gleicher Form mitgeteilt wird, also 3x identisch vorliegt. Würde jetzt z.b. der admin die datenbank nachträglich manipulieren, stände dem immernoch die Kopie der Mail an den Benutzer entgegen, die den Zustand der Checkbox vor der Manipulation zeigt.
Dein verwendeter Code ist sicher eine Eigenkonstruktion. (ist nix Böses, hatte ich auch so, um sicher zu gehen) .
Ob von dir selbst oder von hier übernommen, ist egal. Solche Lösung wurde auch hier im Rahmen der DVSGO-Diskussionen vorgestellt, aber auch eigene Lösungen sind relativ leicht zu bewerkstelligen.
In dieser Lösung ist es wohl so, das dieses Checkbox-Feld nicht identisch ist mit dem Namen, den WB im Form-Modul bzw allgemein in der DVSGO-Zustimmung verwendet und wird daher auch nicht übernommen.
Einfachste Lösung wäre nun, das eigene Kram wieder zu entfernen und die WB-eigene Lösung zu verwenden.
Eine andere wäre, auf einer (versteckten) Probeseite mit solchem Formular und aktivierter DVSGO-Nutzung den Feldnamen für die Checkbox heraus zu finden und diesen in seinem Code zu verwenden
Praktischer wäre natürlich Variante 1, da du damit auch in Zukunft abgesichert bist. Eine mögliche Umbenennung des Feldes in einem der nächsten Upgrades würde dies nämlich system-intern behandeln und du mußt nicht erneut dein Formular anpassen
-
<offtopic>
Da ich gerade am Thema dran bin:
Für sowat kann man auch 'ne Blockchain nutzen :-D
Wb-Bastler auffe Wält, vereinicht euch, macht wat dat jeht.
Blockchain könnte möglicherweise für zukünftige Transaktionen/Beweisketten obligatorisch werden.
In unserem Sandkasten wird das im Zusammenhang mit Urheberrechten diskutiert -so zwischen Juristen und freilaufenden Akademikern :lol:
Die Zukunft war gestern, heute is "mach ma".
</offtopic>
MfG. Evaki
-
Jacobi22, vielen Dank für Deine ausführliche Antwort. Für dieses Formular habe ich nun die entsprechenden Anpassungen gemacht und nutze das von WB in 2.12.1 angebotene Formular. Ich habe somit auch den Text manuell in der DE.php geändert, weil dieser, meines Wissens nach, für die Checkbox des Formulars nicht ausreicht. Der Widerruf inkl. E-Mail-Adresse, wohin der Widerruf geschickt werden soll, muss, soweit ich weiß, mit verankert sein.
Ich habe mir auch die Tabelle in der Datenbank angeschaut. Als Beweis sollte hier sicherlich dann der Wert gelten, der bei submitted_when eingetragen wird. Wenn ich nun die E-Mail des Formularbenutzers erhalte, die er z.B. 8:52 Uhr versendet hat, erhalte ich in dieser die Nachricht: Zustimmung zur Datenschutzrichtlin ie erfolgt Sun, 27 Jan 2019 07:52:32 +0000. Also erfolgte lt. dieser Mail die Zustimmung eine Stunde eher.
Mal davon abgesehen, dass die selbstgebastelte Version nichts in der DB abspeichert, sondern nur die Einwilligung per E-Mail übergibt, nutze ich eigentlich lieber das miniform, da man es sehr hübsch gestalten kann, also eigentlich jedes Feld individuell.
-
Also erfolgte lt. dieser Mail die Zustimmung eine Stunde eher.
um jetzt in die eine oder andere Richtung "meckern" zu können, müßte man deine Zeitzoneneinstellun gen in WB kennen. Üblicherweise wird im Web alle Zeitberechnung von der jeweiligen Serverzeit ausgehend berechnet. Für uns Europäer gilt hier (noch :-D ) UTC, also Londoner Zeit, die bekanntlich eine Stunde hinter der "deutschen" Zeit liegt. (In WB als GMT = Greenwich Main Time verwendet)
Innerhalb von WB kann man diese Zeitzone dann korrigieren, einmal in den WB-Einstellungen, einmal in den User-Profilen und oft auch am Server selbst.
Erst wenn diese Voraussetzungen gegeben sind, kann man schauen, ob da nicht bei WB etwas "falsch" läuft.
Ich habe mir den Spaß mal für dich angeschaut.
WB speichert die Eintragung in der Datenbank (submitted_when) in Serverzeit. Ebenso wird die Angabe in der EMail mit dieser Serverzeit erzeugt. Von daher sind beide Zeiten dann doch gleich.
Das Datum in der Email ist nach RFC 2822 formatiert (http://www.faqs.org/rfcs/rfc2822.html), das ist ein internationaler Standard. Dieser Standard zeigt in den letzten 4 bzw 5 Stellen, hier mal rot markiert -> Thu, 21 Dec 2000 16:01:07 +0200 ) die Zeitzonenverschiebu ng zu UTC. Im Beispiel wären das +2 Stunden, also der Bereich Finnland, Polen, Rumänien, Ägypten usw
In deiner Mail steht Sun, 27 Jan 2019 07:52:32 +0000, es ist also Londoner Zeit bzw eben UTC-Zeit.
Wie gesagt, das ist nichts, was WB erfunden hat....
Ich habe somit auch den Text manuell in der DE.php geändert, weil dieser, meines Wissens nach, für die Checkbox des Formulars nicht ausreicht
da streiten sich wohl die Anwälte gerne drüber. Es gibt Portale (ohne Namen zu nennen) und auch Online-Tutorials diverser Fachanwälte, die da sehr sicher sind, das die Zustimmung in dieser Form und Wortwahl durchaus ausreichend ist, wenn in der verlinkten Datenschutzerklärun g dargelegt wird, was mit diesen Daten passiert und wie man widersprechen kann. Diese Anwälte argumentieren mit Logik. Wenn ich mich für einen z.b. Newsletter anmelde, möchte ich natürlich diesen (per Mail) erhalten. Und da ist es logisch, das das System meine Emailadresse aus dem Formular auch speichert. Ich teile Webmastern auch gern über deren Kontaktformular einen entdeckten Fehler mit und da möchte ich natürlich, das meine Info ihn auch erreicht, also in irgendeiner Form übermittelt wird, im rechtlichem Sinne also "verarbeitet" - logisch, oder?
Ich hatte bzw habe Kontakt zum Datenschutzbeauftra gten eines größeren deutschen Unternehmens und dem war das nicht ausreichend und er hätte da gerne diesen Text:
Sie stimmen der Verarbeitung und Speicherung Ihrer Daten gemäß unserer Datenschutzerklärun g zu. Hinweis: Sie können Ihre Einwilligung jederzeit per Mail an info@xxxxxxx.de widerrufen.
In anderen dort verwendeten Formularen steht dann auch jeweils eine andere Formulierung. Man muß es also für jeden Fall anpassen.
-
Nein, ich wollte nicht meckern, nur mitteilen. Im WB selbst in den Optionen und auch im UserProfil ist GMT+1 eingestellt, was man ja, wenn die Sommerzeit in Kraft tritt, wieder auf GMT+2 umstellen müsste :-o Die Serverzeit kommt von Strato und lässt sich wohl nicht anpassen bei einem normalen Webhosting-Paket. Das ist ja schon immer so.
Ja, die Anwälte streiten sich immer gern. Ist ihr Job :-) Die einen sagen eben halt auch, dass es genügt, eine ausgedruckte Mail zu haben, auf der vermerkt ist, dass der User der Datenschutzerklärun g zugestimmt hat. Und ich zweifle hier sogar an, dass jeder eine solche (Anfrage)Mail ausdruckt bzw. die Mail überhaupt als „Beweis“ behält.
-
Ich lese Serverzeit.
Das ist üblicherweise die Ortszeit (date.timezone = "Europe/Berlin"), nicht die in WB zur Berechnung herangezogene und voreingestellte UTC. Warum immer noch eine händische Umstellung zu GMT+1/GMT+2 in WB selbst benötigt wird - keine Ahnung.
In alten WB-Versionen, also vor der Umstellung auf UTC, hatten meine/unsere Anwender eine automatische So/Winter-Umschaltung "eingebaut". Es wurde im Herbst erneut darüber nachgedacht "sowas" wieder einzubauen.
MfG. Evaki
-
Nein, ich wollte nicht meckern, nur mitteilen.
Hallo, völlig zu recht bemängelst du das.
Denn wenn dort die Zeitzone angezeigt werden soll wie sie in Optionen oder Mein Profil ausgewählt wurde, dann kann da nicht immer +0000 stehen. Bei mir ist in Optionen +2 und im Profil +1 ausgewählt, die Email zeigt trotzdem +0000.
Der gleiche Code zeigt aber auf der Bestätigungsseite und in einer Code Section die korrekte Zeit (ohne +xxxx).
-
Evaki: Es wurde im Herbst erneut darüber nachgedacht "sowas" wieder einzubauen.
Ich korrigiere. Es wurde bei einigen Anwendern wieder (in's Template!) eingefügt. Die So/Wi-Zeitumschaltung erfolgt -für die WB-Systemzeit unter Optionen- somit automatisch.
<?php
// sieht dann ungefähr so aus
date_default_timezone_set('Europe/Berlin');
echo "\n Zeitzone:\n "; echo date("T j.n.Y H:i"),"<br />";
echo "\n Gesetzte Zeitzone:\n " . date_default_timezone_get() . '<br />';
$cet= date("T");
$cest= date("T");
if($cet ==='CET'){
echo "\n Is Wintä\n ";
// $database->query("UPDATE ".TABLE_PREFIX."settings SET value='3600' WHERE ............
}else{
if($cest==="CEST"){
echo "\n Is Sommä ";
// $database->query("UPDATE ".TABLE_PREFIX."settings SET value='7200' WHERE ...................
}else{
}}
?>Funktioniert anscheinend wie gehabt per CET/CEST-Erkennung.
Habe es aber selbst noch nicht ausprobiert, ob das funktioniert.
MfG. Evaki
Ein Nachtrag: Habe es soeben mal lokal angeschaut. Wenn man den Monat auf den Sommer verlegt, gibts auch "Is Sommä"
-
*wech
-
Nein, ich wollte nicht meckern, nur mitteilen.
ich dachte da auch eher an mich :wink: ich korrigiere meinen Satz oben gern in
Damit ich in die eine oder andere Richtung "meckern" kann,
Denn wenn dort die Zeitzone angezeigt werden soll wie sie in Optionen oder Mein Profil ausgewählt wurde, dann kann da nicht immer +0000 stehen. Bei mir ist in Optionen +2 und im Profil +1 ausgewählt, die Email zeigt trotzdem +0000.
man muß es dann auch lesen...........
die Funktion date(r), die in der Mail verwendet wird, hat mit WB nichts zu tun, bekommt keine Daten von WB, nur den Auftrag, die UTC-Zeit zu ermitteln. Das ist weltweiter Standard in der Zeitübermittlung beim Datentransport. Steht dort die reine Uhrzeit ohne Bezug, weiß niemand, aus welcher Zeitzone ein Dokument versendet wurde, Moskauer Zeit, New Yorker Zeit usw. Man kann sicher darüber diskutieren, ob man nicht im Sinne der Benutzerfreundlichk eit eine andere Form der Ausgabe hätte wählen können
Das ist üblicherweise die Ortszeit (date.timezone = "Europe/Berlin"),
so nicht richtig
die meisten Server der Welt, egal mit welcher Sprache sie arbeiten, beziehen sich auf UTC, durch date.timezone kannst du in PHP aber dort schon eine Zeitverschiebung für diese Domain erreichen. Bei einem Server mit 20 Plätzen kann also jeder eine andere date.timezone für sich einstellen. Die Serverzeit aus date(r) wird dir trotzdem auf allen 20 Plätzen die gleiche UTC-Zeit anzeigen.
WB arbeitet vom Grundsatz her ausgehend von UTC (framework/initialize.php - \date_default_timezone_set('UTC'); )
Die gesamte TIMEZONE-Berechnung basiert auf dieser Einstellung. Sicherlich kann man das für sich anpassen, aber dann muß man in den Zeitzoneneinstellun gen auch umrechnen.
An der Ausgabe der Uhrzeit in der Mailbestätigung ändert diese Umstellung aber nichts.
-
die meisten Server der Welt, egal mit welcher Sprache sie arbeiten, beziehen sich auf UTC, Die meisten Server der Welt, egal mit welcher Sprache sie arbeiten, hatten vor Jahren die lokale (PHP)-Zeit voreingestellt. Kenne keinen Server wo das vor 2000 anders war. Rechnen konnte man ja weiterhin, eben bis heute, mit jeder Anwendung, wie auch WB-intern, mit UTC bzw Unixtime. Es hat sich nur die Voreinstellung :wink: geändert, die in vielen Fällen selbst konfiguriert werden kann/muß.
Bei einem Server mit 20 Plätzen kann also jeder eine andere date.timezone für sich einstellen. Eben, das gesagte bleibt davon unberührt. Macht ja auch nur in wenigen Fällen Sinn etwas anderes als die lokale Zeit einzustellen bzw vorzugeben. Hat man 'nen Server in den USA, aber mit einem europäischen Angebot, bringts naürlich nix, irgend eine Zeitzone der USA einzustellen.
Was man letzlich nutzt, ist jedem selbst überlassen, ob CMS oder Nutzer/Anwender.
MfG. Evaki
-
Ganz vergessen:
Erst durch die Nutzung der (php)-Zeitzonen wird eine automatische So/Wi-Umschaltung möglich.
Ansonsten bleibt einem nur die händische Umschaltung, wie sie halt im Moment vorgegeben ist.
MfG. Evaki
-
Die einen sagen eben halt auch, dass es genügt, eine ausgedruckte Mail zu haben, auf der vermerkt ist, dass der User der Datenschutzerklärun g zugestimmt hat. Und ich zweifle hier sogar an, dass jeder eine solche (Anfrage)Mail ausdruckt bzw. die Mail überhaupt als „Beweis“ behält.
Als Besucher muß man das überhaupt nicht
Der Besucher hat durch die DVSGO die Möglichkeit, zu jeder Zeit den Betreiber einer Webseite zu fragen, welche Daten von ihm auf dem Server gespeichert wurden. Dann gibt es eine Antwort vom Betreiber, in der dann alles drin stehen muß. Und hier wäre dann der Betreiber in der Beweislast, nicht der Besucher.
Seine Mail z.b. aus einem Kontaktformular landet so oder so im System, wenn er der Datenschutzerklärun g zugestimmt hat. Lehnt er es ab, darf sie garnicht erst versendet werden.
Der Besucher hat ebenfalls die Möglichkeit, der Speicherung seiner Daten formlos zu widersprechen. Das kann er 5 Minuten nach seiner erteilten zustimmung machen oder zwei Jahre später. Und darauf hat der Betreiber dann zu reagieren.
Für beide Fälle (Datenauskunft und Widerspruch) braucht es eine penible Buchführung, denn hier muß man im Zweifel wirklich als Betreiber nachweisen, was man wann in welcher Form bekommen hat und wie reagiert wurde.
die meisten Server der Welt, egal mit welcher Sprache sie arbeiten, hatten vor Jahren die lokale (PHP)-Zeit voreingestellt
1994 hab ich begonnen mit dem Kram und sicher in den Jahren tausende Server gesehen, meine eigenen, von Usern, von Kunden und da war keiner dabei, der nicht auf UTC basierte
Eben, das gesagte bleibt davon unberührt. Macht ja auch nur in wenigen Fällen Sinn etwas anderes als die lokale Zeit einzustellen bzw vorzugeben
Dein Problem: bei dir ist Domain == Server. Das ist aber nicht so. Bei den Discountern hat man auch mal 500 Plätze neben sich. Bei meinem Strato-Paket sind noch 19 weitere Pakete auf diesem Server
Hat man 'nen Server in den USA, aber mit einem europäischem Angebot, bringts naürlich nix, irgendeine Zeitzone der USA einzustelln.
Auch hier brauche ich irgendeinen festen Bezug. Nimm einen Shop in Deutschland gehostet, in den USA administriert, der Kunde kauft was um 12.00 Uhr MEZ, UTC+1, das ist 6.00 Uhr EST, UTC -5, dann weiß der Betreiber in New York, das er in 6 Stunden etwas verkauft? :-o Und all seine Buchführung, seine Logs, seine Mails sind dann 6 Stunden in der Zukunft? So läuft das nicht. Genau dafür gibt es die Zeitzoneneinstellun g in den User-Accounts. Du hast einen Timestamp der Serverzeit und rechnest die TIMEZONE der jeweiligen User dazu oder ab und bist immer beim gleichem Ausgangswert, dem in WB festgelegtem UTC. Festgelegt darum, weil es nur ein System geben kann und das soll für den User in Spanien, USA oder Moskau genauso funktionieren wie für den User in Berlin oder Hamburg. Ich kann meinen Server umstellen auf Europe/Berlin, aber kann User Paul das auch? Und wenn nicht, wohnt er in der gleichen Zeitzone? Mein erster Strato-Server hatte diese Einstellung im Admin-Panel, Standort, Sommerzeit ja/nein.
Sommerzeit finde ich kaum noch, weil es eben softwareseitig mit den date_timezones gemacht wird, entweder direkt in der php.ini oder im Code.
Bevor das aber zur Schreiborgie auswuchert, du hast doch jede Menge Möglichkeiten mit diversen WB-Backups. Ändere doch mal die date_default_timezo ne_set('UTC'); auf date_default_timezo ne_set('Europe/Berlin');
idealerweise in einer europafernen Installation oder nutze die New Yorker Zone in einer deutschen Installation, dann wirst du schnell merken, das da nichts mehr stimmt, eine News, die du "morgen" geschrieben hast, kann ich dann heut schon lesen :-o :-o
Ist eigentlich auch nicht meine Aufgabe, das zu erklären, sondern eher die des Supports. Der sollte wissen, was man da wo warum eingebaut hat. Grundsätzlich hatte das System von Ryan, das ja vom Grundprinzip in jedem CMS so arbeitet, schon Hand und Fuss.
-
Du hast einen Timestamp der Serverzeit und rechnest die TIMEZONE der jeweiligen User dazu oder ab und bist immer beim gleichem Ausgangswert, dem in WB festgelegtem UTC. Das alles ändert nichts daran, daß Zeitzonen keine festgezurrte Größe sind, sondern sich auch verändern können, wie z.B. bezgl. der So/wi-zeit. Und ob der Kunde nun UTC oder seine Ortszeit angezeigt bekommt, liegt dem CMS zugrunde. Manchmal ist's auch die Frage nach Kundenfreundlichkei t, denn wer rechnet z.B. bei einer Mail nach, um wieviel Stunden die Verschiebung zu UTC ist. Bei einem Webauftritt in Bremen erwartet man im Kalender auch keine UTC.
Mal ganz ketzerisch gefragt, wem nutzt die Ortseinstellung unter Optionen, und warum sollte sich die nicht automatisch nach So/Wi einstellen bzw anpassen? Ist das jetzt zurück zu den Wurzeln, also Handwerk?
MfG. Evaki
-
Im übrigen braucht es ausnahmsweise keine langen Erklärungen zum grundsätzlichen Verhältnis von Unixtime, Weltzeit, Lokalzeit. Einer der wenigen Themen... Einzig die WB-Interna sind mir, wie vieles andere nicht vertraut. Solange es hier keine Probleme gibt, ist ja alles in Ordnung.
Mein Thema bzw. die Frage war, warum es nicht sinnvollerweise eine automatische Umschaltung der So/Wi-Zeit gibt. Da ist's doch vollkommen egal, wie WB mit Zeit umgeht und warum.
MfG. Evaki
-
wem nutzt die Ortseinstellung unter Optionen,
die deutsche Brille 8-) 8-) 8-) 8-)
Über das Thema würden wir überhaupt nicht reden, wenn wir hier nicht in Mitteleuropa wären.
Muß ich jetzt wirklich (für dich) einen WB-Grundkurs machen?? :-o :-o :-o
Damit wird die Zeitverschiebung zu UTC als Bezugspunkt für das WB-System und nicht-eingeloggte User eingestellt.
Die Ausgabe dieser dort eingestellten Zeit erfolgt z.b. in News-Artikeln, in Mails unangemeldeter Besucher, Gästebuch usw. Eben alles, was für unangemeldete Besucher an Uhrzeiten im Frontend sichtbar ist.
Loggt sich nun ein Besucher ein und hat eine von dieser Systemuhrzeit abweichende Zeitzone, wird dieser Wert auf den UTC-Timestamp addiert bzw abgezogen und er sieht statt der Systemzeit seine Zeit.
Zum besserem Verständnis ein Beispiel:
Ein Server (mit UTC), ein WB in Deutschland mit GMT+1, zeigt eine News mit Datum und Zeit vom 29.01.19 - 12.00 Uhr - Das sieht der nicht angemeldete User in New York und in Sydney. Bei jedem steht 12.00 Uhr. Und auch, wenn das jetzt gut 40 min her ist, wäre es in Sydney schon 22.00 uhr, in New York erst um 6.00 Uhr
Habe ich die Domain und die Administration aber in Sydney, wäre es wohl Quatsch, die deutsche Zeitzone zu verwenden. noch schlimmer wird es in den USA, denn dann läge jedes Posting 6 Stunden in der Zukunft. Der Amerikaner in New York stellt also sein WB auf GMT -5, der Kollege in Sysney auf GMT +10
In den jeweiligen Postings wird dann die eingestellte Zeitzone des Adminbereichs gezeigt und damit kann kein Posting in der "Zukunft" erscheinen, sondern in "Ortszeit"
Als wir damals dieses date_default_timezo ne_set('UTC'); in die (ich glaube) WB 2.10 eingebaut hatten, gab es hier natürlich Überlegungen, Vorschläge und auch verschiedene Beiträge hier, weil der Ex-Kollege aus Kanada z.b. Probleme hatte mit UTC. Hier muß man wissen, das nicht jeder Server dies auch genau so definiert. Manche verwendeten dort UTC, andere haben garkeine Einträge und überlassen es der Software und dann steht man im Programm da ohne einen gültigen Wert. Man braucht also einen default-Wert und der ist nun mal seit Anbeginn UTC.
Für ein rein deutsches Projekt mit ausschließlich deutschen Admins und Besuchern mag ein Europe/Berlin richtig sein und sieht natürlich einfach aus, aber wehe irgendeiner kommt dann aus einer anderen Zone
Mein Thema bzw. die Frage war, warum es nicht sinnvollerweise eine automatische Umschaltung der So/Wi-Zeit gibt. Da ist's doch vollkommen egal, wie WB mit Zeit umgeht und warum
ja, das Problem verfolgt dich schon Jahre, mindestens 8 :-D :-D :-D
bin ich aber der falsche Ansprechpartner, frag den Support oder die Dev's. Ich schätze mal, weil es ein sehr komplexes System innerhalb von WB ist und jedes Modul, das in irgendeiner Form eine Zeit verwendet, genau davon abhängt. Üblicherweise wird an den Timestamp an fast jeder Stelle die Timezone dran gehängt, beim Schreiben und beim Lesen, nehm ich aber Europe/Berlin, wird mir überall die 3600 bzw 7200 Sekunden draufgerechnet, die wir hier wohl alle eingestellt haben und die in vielen Timestamps in der DB schon eingerechnet sind.
Ich mü0te also bei einem Wechsel JEDEN Timestamp in der DB kontrollieren, wie er geschrieben wurde, mit oder ohne Timezone, müßte entsprechend rechnen und neu schreiben und das alles in einem Upgrade. Kannst du gern versuchen... :wink:
Das Manko ist eben, das dir am Ende jeglicher Bezug zu irgendeiner festen Größe fehlt. Bei einem Serverumzug in eine andere Zeitzone hast du alles falsche Zeitdaten. Was allerdings technisch kein Problem gewesen wäre, ist, das bei der Ermittlung der Zeitzone durch aus die Möglichkeit bestanden hätte, für die eingestellte WB-Systemzeit eine mögliche Sommerzeit zu ermitteln, auch das geht mit der date()-Funktion und dann rechnet man eben nochmal einen Wert drauf oder ab. setzt wiederum voraus, das diese Einstellungen in den WB-Settings auch korrekt sind.
Nu aber genug gephaselt, der Doc wartet...
-
Nix erklären muß!
Ich weiß es (in diesem Falle :lol: ).
Aber es wird über Deine Erklärungen eben noch(mal) deutlicher
"Bei einem Serverumzug in eine andere Zeitzone hast du alles falsche Zeitdaten."
So zumindest wurde mir auch von Anwendern berichtet, kann das aber nicht nachprüfen; wollte auch nicht, da zu seltener Fall. Wahrhaben wollte ich's wahrscheinlich auch nicht (ist schon länger her)
Und das auch bei händischer Umstellung +/-Timezone, also ganz ohne Automatik?
Wenn dem wirklich so wäre, das weiß ich eben nicht! WB-Interna, und wie schon gesagt..., wäre das beim Umzug eine Katastrophe. Kann das sonstwer bestätigen? Wäre ja sowas wie'n Designfehler.
MfG. Evaki
-
Apropos "Designfehler"
Der würde ja auch schon bei händischer Umstellung in Erscheinung treten, wie z.B. bei einem Kalender. Erscheint mir nicht logisch, und wäre bestimmt schon aufgefallen.
Auch kann ich mir das beim besten Willen bei einer D.V. nicht vorstellen.
MfG. Evaki
-
Ich hab das jetzt so verstanden:
In der Email die Zeitangabe mit +0000 is korrekt, weil klar sein soll, dass dies die UTC Zeit ist wie sie auch in der DB gespeichert wurde.
Von daher alles korrekt.
-
In der Email die Zeitangabe mit +0000 is korrekt, weil klar sein soll, dass dies die UTC Zeit ist wie sie auch in der DB gespeichert wurde.
Man kann ja trotzdem drüber nachdenken, ob das in einer nächsten Version nicht anwenderfreundliche r ausgegeben werden kann, das wären im Code neun Zeichen mehr plus eine Klammer drum herum. Dies wäre reine Optik und ändert nichts an dem, was in der DB steht, verhindert aber Mißverständnisse wie dieser Thread zeigt.
"Bei einem Serverumzug in eine andere Zeitzone hast du alles falsche Zeitdaten."
So zumindest wurde mir auch von Anwendern berichtet, kann das aber nicht nachprüfen; wollte auch nicht, da zu seltener Fall. Wahrhaben wollte ich's wahrscheinlich auch nicht (ist schon länger her)
Und das auch bei händischer Umstellung +/-Timezone, also ganz ohne Automatik?
Wenn dem wirklich so wäre, das weiß ich eben nicht! WB-Interna, und wie schon gesagt..., wäre das beim Umzug eine Katastrophe. Kann das sonstwer bestätigen? Wäre ja sowas wie'n Designfehler.
ich versuch es noch einmal...
WB hat seit der Gründung den zeitlichen Bezug auf UTC bzw GMT. Ein Londoner WB-Admin wird nix verstellen und bleibt also dabei. Bei jeder Zeit-Verwendung wird nun geschaut, welche aktuelle UTC-Zeit haben wir? 17.00 Uhr - nehm ich. Dieser Bezugspunkt ist für alle gleich, in Australien oder Chile
Ändere ich aber in der framework/initialize.php (oder in nachfolgenden Scripten) diesen Bezug auf eine andere Zone, z.b. eben nach date_default_timezo ne_set('Europe/Berlin'), rechnet das komplette WB-System (und auch jedes andere CMS) ausgehend von dieser Zeitzone
Der Kollege Admin in Sydney, der natürlich dann Australia/Sydney wählt und mit dir live in einer Teamviewer-Konferenz einen gleichen Beitrag einfügt, bekommt dann seine Ortszeit - macht 17.00 Uhr plus 10 Stunden, also morgen um 03.00 Uhr. Kein Problem, solang ich Gast auf seiner Seite bin, der Gast bekommt die Ortszeit. Hab ich aber einen Account dort, muß ich das mit meiner User-Zeitzone korrigieren oder ich sehe eben einen Beitrag von morgen.
Nun zieh solch Domain um nach NewYork oder gar nach Hawaii und ändere dann die Zeitzone, dann bist du fast 24 Stunden voraus ;-)
Und das kann eben mit Bezug auf UTC nicht passieren, weil alles einheitlich ist
-
Lieber "jacobi22"
habe den Eindruck, daß wir aneinander vorbei reden.
Alles von Dir vorgetragene wird nicht in Zweifel gezogen.
Es wurde zudem auch noch verstanden :D , u.a. weil auch weitestgehend bekannt
Nun mal nacheinander, also nacheinander aufsetzend.
NTP: Unixtime (=UTC)
Motherboard : Systemzeit (NTP)
Server (z.B. Apache): Per default überall auf Systemzeit. Ist zwar selten, aber per Modul auch auf eine lokale Zone einstellbar.
PHP: Per default auf Systemzeit, hat aber in jeder Kompilierung eine Zonentabelle dabei.
Ändern sich Zonen schneller als erwartet, bindet man besser die Olsen-Datenbank ein, da diese immer aktueller, also nicht an Releasezyclen gebunden ist.
Jeder PHP-Anwendung steht es nun frei, unterschiedliche Zeitreferenzen zu nutzen.
Zum Beispiel ein CMS, das intern alles über die Systemzeit (s.o.) berechnet, für die Präsentation aber sehr wohl die lokale Zeit für bestimmte Zwecke nutzen kann, wie z.B. einen So/Wi-Wechsel.
Das angegebene Script nutzt nun die PHP-Zonentabelle, um die Zeiteinstellung unter "Optionen" selbsttätig die Umstellung Sommer-/Winterzeit vorzunehmen.
Mehr is nich.
Per SQL-DB geht zwar auch noch was, aber ist hier nicht relevant.
Den oben angegeben Kram, habe ich zum Teil in unserem Serverraum selbst installiert.
Wobei hier noch eine Synchronisation per DCF77 hinzukam, mit den entsprechenden PCI-Karten.
MfG. Evaki
-
Jau, und nun machst du das bitte für alle WB-Downloader gleich :wink:
eigentlich gehts ja nur um die Sommerzeit und das andere Systeme da einen Knopf haben. Wie gesagt, hab ich nie verstanden, warum das stets abgelehnt wurde, aber ich bin halt kein Informatiker ;-)
-
hab ich nie verstanden, warum das stets abgelehnt wurde
Habe nur in Erinnerung (lang ist's her), daß die Zeiteinstellung (GMT+/-) sehr aufwendig ist, speziell die userspezifische. Dann gabs plötzlich ganz andere Aufgaben und Probleme um WB herum: Rotation, Rotation, Rotation...
Ups, der Freudsche hat ja zugeschlagen.
Olson-DB heißt die. Is ja nicht die vonne Olsen-Bande.
MfG. Evaki