Zeitzone

[webald]

Wird eigentlich schon irgendwo im Shop eine Zeitzone fesgelegt/genutzt?

Ich bau gerade einen Kalender und da ist das ja nicht ganz unerheblich.

Linkback: https://www.modified-shop.org/forum/index.php?topic=35436.0

[Bonsai]

Suche doch einfach mal mal 'timezone' in allen Dateien!

z.B. das wird gefunden:
/admin/includes/application_top.php

Code: PHP  [Auswählen]

// default time zone
if (version_compare(PHP_VERSION, '5.1.0', '>=')) {
date_default_timezone_set('Europe/Berlin');
}
 

[webald]

Das ist hardcoded, ich meinte eigetnlich ob das irgendwo eingestellt wird.

[webald]

Nachfrage:

Ich brauch das für einen Terminkalender. Zur Speicherung der Termine gibt es in meinen Augen 2 Möglichkeiten:

1. Datum/Uhrzeit als UTC speichern und zur Anzeige im Shop umrechnen auf die Shop-Zeitzone
2. Speichern in lokaler Zeit, dafür zusätzliches Feld Zeitzone in der DB

Was wäre zu bevorzugen?

Das bringt mich zur nächsten Frage:
Im Shop gibt es zahlreiche Abfragen welche die SQL-Funktion NOW() nutzen. Wäre ein UTC_TIMESTAMP() in vielen Fällen nicht richtiger?
Könnte hiermit http://www.modified-shop.org/forum/index.php?topic=35404.msg323057#msg323057 auch zusammenhängen.

[Bonsai]

Aus mehreren Jahren Erfahrung als Systemadmin in hochkomplexen IT Umgebungen würde ich sagen, alles was nicht UTC speichert ist Schrott und produziert die wildesten Fehler.
Da hier aber nur zwei Systeme betroffen sind, Apache und MySQL, würde ich es genau so machen, wie es die anderen Programmierer des Shopsystems für andere Funktionen umgesetzt haben. Ansonsten stiftest Du Verwirrung. Soweit ich das sehe, kann der Shop nur eine einzige Zeitzone. Wenn Du unbedingt mehrere Zeitzonen unterstützen musst, ist das aber Benutzer-abhängig. Dann muss das Feld Zeitzone in die customers Tabelle.

Ich würde in dem Fall Option 3 bevorzugen:
Speichern in UTC und zusätzliches Feld Zeitzone in DB in der customers Tabelle.

Contries wäre Unfug ... USA hat ja schon 4 oder 5 Zeitzonen. Russland noch mehr.

[webald]

Bin in meinen Überlegungen genau an diesem Punkt.

countries: was sollte man als (Standard-)Wert für USA nehmen??? Evtl. die Zeitzone der Hauptstädte?
zones:  ginge, aber dann muss man immer auch das Bundesland als Auswahl anbieten.

Ich bin in meinen Überlegungen für einen Terminkalender soweit, dass die Zeit immer lokal bezogen auf den Veranstaltungsort angegeben wird. Bespiel: Firma teilt Messetermin in Moskau, Paris, New York und Denver. Die Öffnngszeiten sollte da dann schon in der lokalen Zeit stehen, wofür natürlich die passenden Zeitzone irgendwo und irgendwie zu ermittlen sein muss. Die Shopzeitzone ist damit aber ungeeignet.

[webald]

... würde ich sagen, alles was nicht UTC speichert ist Schrott und produziert die wildesten Fehler...

+

Das bringt mich zur nächsten Frage:
Im Shop gibt es zahlreiche Abfragen welche die SQL-Funktion NOW() nutzen. Wäre ein UTC_TIMESTAMP() in vielen Fällen nicht richtiger?

Dann sollte mandas evtl auch mal angehen?

[Bonsai]

Ja! Wobei modified primär ein deutsches System ist und fast nur im deutschsprachigen Raum verbreitet ist. In deutschsprachigen Ländern gibt es nur eine Zeitzone. Es treten also nur dann Probleme auf, wenn der Provider murkst und seine Server nicht mit einem Zeitserver abgleicht. Wäre Modified ein englisches System, wäre man damit schon lange auf die Fresse geflogen. Wenn man z.B. so wahnsinnig ist und bei einem US Provider hostet kann das auch passieren ..... da ist der Apache nicht unbedingt in der gleichen Zeitzone wie der MySQL ....

Hast Du mal eine Windows Domäne erlebt, bei der die Domaincontroller nicht Zeitsyncron sind?  Ich habe mal erlebt, dass wegen einer Fehlkonfiguration + Server aus der Zeit gelaufen ALLE Domaincontroller im permanenten Neustart festhingen. Von Johannisburg bis Kopenhagen und Madrid bis Marburg. 
Administrier mal einen Computer, der nur 40 Sekunden erreichbar ist, bevor er wieder runterfährt ... 

[webald]

Hast Du mal eine Windows Domäne erlebt, bei der die Domaincontroller nicht Zeitsyncron sind?  Ich habe mal erlebt, dass wegen einer Fehlkonfiguration + Server aus der Zeit gelaufen ALLE Domaincontroller im permanenten Neustart festhingen. Von Johannisburg bis Kopenhagen und Madrid bis Marburg. 
Administrier mal einen Computer, der nur 40 Sekunden erreichbar ist, bevor er wieder runterfährt ... 

Stecker ziehen, ntdsutil, ADSIEdit und wieder neu rein?

[Bonsai]

Da es eine VM war ... Netzwerkkarte deaktiviert (dann rebootete er nicht mehr), eventlog durchsucht, festgestellt dass der Reboot immer nach starten des Anmeldedienstes erfolgte, den Dienst deaktiviert, Netzwerkkarte wieder an, gebootet, 2 Minuten gewartet, Dienst wieder an, Problem weg.
Einen Tag später kam Rückmeldung von M$, wir mussten irgendeinen RegKey setzen. Ob der Kye das Problem wirklich behoben hat weiß keiner, weil in der Domain danach nie wieder die Server nicht Zeitsyncron waren.

[webald]

OT:
der Regkey war bestimmt die Tombstonezeit. Aber das mit dem Anmeldedinest muss ich mir merken.

[webald]

So, ich habe dann mal angefangen die Tabelle countries als Basis um Zeitzone zu erweitern. Allerdings finde ich für einige Länder keine Passende Zeitzone:

29   Bouvet Island   BV   BVT
60   Dominican Republic   DO   DOM
85   Greenland   GL   GRL
232   Virgin Islands (U.S.)   VI   VIR

Die Zeitzone muss in $timezones = DateTimeZone::listIdentifiers(); enthalten sein, um eine Umrechung nach UTC zu ermöglichen.

Was wäre (einigermaßen) korrekt? Gerne auch Korrekturen zur angehängten Datei.