2
UTC oder LOC das ist hier die Frage?
Zwei Abteilungen die unterschiedlich entwickeln, sollen sich auf eine Zeit einigen. Es gibt für beide Seiten Vor- und Nachteile. Welches ist der sinnvollere Weg?
Hallo Community,
ich habe gerade die Aufgabe Pro und Contras zu beschreiben in welcher Zeitzone, „Zeitstempel“ abgelegt werden sollen/sollten bei einer Software, in einer Datenbank. Es soll eine Lösung für alle Abteilungen gefunden werden die dann bindend wird.
Es gibt hier die konkrete Anforderung, dass ich sowohl den Entwicklern gerecht werde (die auch später den Support durchführen) als auch den Bedienen der Software, die im schlimmsten Fall Emma aus dem Tante Emma Laden sein kann. (Es handelt sich aber um eine Industrieanwendung)
Es ist dabei durchaus möglich das Entwickler und Emma nicht in der gleichen Zeitzone Unterwegs sind. Was nicht passiert ist, dass die Anwendung über das Netzwerk in zwei verschiedenen Zeitzonen betrieben wird.
Konkret habe ich hier zwei Abteilungen die Ihre Datenbankereignisse mit Zeitstempeln versehen.
Abteilung A:
Speichert alle Zeitstempel in UTC und wandelt diese in der Oberfläche in LOC um, wenn Bedarf besteht.
Abteilung B:
Speichert alle Zeitstempel in LOC und zeigt dies auch so in der Oberfläche an. (Bei Bedarf)
Abteilung A sagt: „Da ich nicht weiß, wo in welchen Land welche Sommer/Winterzeiten und Offset herrscht, werden alle Zeiten in UTC gespeichert und für den „dummen“ Anwender werden die benötigten Zeiten umgerechnet und in der Oberfläche Dargestellt.
Somit kann zeitzonenunabhängig jedes Problem identifizieren und Zeitzonenunabhängig behandelt werden. Jeder redet von der gleichen Zeit, egal wo Supporter und Anwender und Entwickler sich gerade aufhalten. Der „Supporter/Entwickler“ muss sich nicht um die Sommer/Winter und Offset Zeit gekümmert werden.“
Abteilung B sagt: „Ich bin Entwickler und die verschiedenen Zeitzonen interessieren weder mich noch den Anwender. Der Anwender lebt und arbeitet in LOC. Der Anwender sagt um 15Uhr hatte ich ein Problem mit der Software und somit möchte ich als Entwickler auch im LOG und in der Datenbank die Zeitstempel sehen die LOCAL sind und gerade nicht die UTC Zeiten die erst umgerechnet werden müssen.
Ansonsten müsste der Entwickler bei Zugriff auf die Datenbank immer die Zeitzonen (Notfalls) im Kopf umrechnen. Das geht schief sagen die Entwickler. Ebenfalls ist es auch egal ob Sommer/Winter oder sonst was ist, weil an dem Standort alle Geräte auf die Gleiche Zeitzone eingestellt sind.
Beide Begründungen haben ihren Scharm, dennoch muß eine Abteilung umdenken und Ihre Werte ändern, was natürlich keiner gerne macht, weil Mehraufwand. Deshalb bin ich für ein konstruktives Brainstorming dankbar.
Grüße
WirCom
ich habe gerade die Aufgabe Pro und Contras zu beschreiben in welcher Zeitzone, „Zeitstempel“ abgelegt werden sollen/sollten bei einer Software, in einer Datenbank. Es soll eine Lösung für alle Abteilungen gefunden werden die dann bindend wird.
Es gibt hier die konkrete Anforderung, dass ich sowohl den Entwicklern gerecht werde (die auch später den Support durchführen) als auch den Bedienen der Software, die im schlimmsten Fall Emma aus dem Tante Emma Laden sein kann. (Es handelt sich aber um eine Industrieanwendung)
Es ist dabei durchaus möglich das Entwickler und Emma nicht in der gleichen Zeitzone Unterwegs sind. Was nicht passiert ist, dass die Anwendung über das Netzwerk in zwei verschiedenen Zeitzonen betrieben wird.
Konkret habe ich hier zwei Abteilungen die Ihre Datenbankereignisse mit Zeitstempeln versehen.
Abteilung A:
Speichert alle Zeitstempel in UTC und wandelt diese in der Oberfläche in LOC um, wenn Bedarf besteht.
Abteilung B:
Speichert alle Zeitstempel in LOC und zeigt dies auch so in der Oberfläche an. (Bei Bedarf)
Abteilung A sagt: „Da ich nicht weiß, wo in welchen Land welche Sommer/Winterzeiten und Offset herrscht, werden alle Zeiten in UTC gespeichert und für den „dummen“ Anwender werden die benötigten Zeiten umgerechnet und in der Oberfläche Dargestellt.
Somit kann zeitzonenunabhängig jedes Problem identifizieren und Zeitzonenunabhängig behandelt werden. Jeder redet von der gleichen Zeit, egal wo Supporter und Anwender und Entwickler sich gerade aufhalten. Der „Supporter/Entwickler“ muss sich nicht um die Sommer/Winter und Offset Zeit gekümmert werden.“
Abteilung B sagt: „Ich bin Entwickler und die verschiedenen Zeitzonen interessieren weder mich noch den Anwender. Der Anwender lebt und arbeitet in LOC. Der Anwender sagt um 15Uhr hatte ich ein Problem mit der Software und somit möchte ich als Entwickler auch im LOG und in der Datenbank die Zeitstempel sehen die LOCAL sind und gerade nicht die UTC Zeiten die erst umgerechnet werden müssen.
Ansonsten müsste der Entwickler bei Zugriff auf die Datenbank immer die Zeitzonen (Notfalls) im Kopf umrechnen. Das geht schief sagen die Entwickler. Ebenfalls ist es auch egal ob Sommer/Winter oder sonst was ist, weil an dem Standort alle Geräte auf die Gleiche Zeitzone eingestellt sind.
Beide Begründungen haben ihren Scharm, dennoch muß eine Abteilung umdenken und Ihre Werte ändern, was natürlich keiner gerne macht, weil Mehraufwand. Deshalb bin ich für ein konstruktives Brainstorming dankbar.
Grüße
WirCom
Share on Facebook
Share on Twitter
Share on Reddit
Share on LinkedinPlease also mark the comments that contributed to the solution of the article
Content-Key: 196667
Url: https://administrator.de/contentid/196667
Printed on: April 19, 2024 at 22:04 o'clock
2 Comments
Latest comment
Hallo,
wir haben das so gelöst das alle Server und Anwendungen mit UTC laufen. Somit kann ich auch in den Logs genau nachsehen. Im Frontent wird das dann umgerechnet damit der Anwender nicht denken muss.
Gruß
wir haben das so gelöst das alle Server und Anwendungen mit UTC laufen. Somit kann ich auch in den Logs genau nachsehen. Im Frontent wird das dann umgerechnet damit der Anwender nicht denken muss.
Gruß
Hallo Hitman4021,
danke für das schnelle Feedback. Das ist natürlich eine Möglichkeit. Die Abteilung B sagt aber. Naja…das stimmt schon, aber heute hatte ich vier verschiedene Supportfälle mit 4 verschiedenen Zeitzonen. Somit müsste 4x umgerechnet werden auf Supporter Sicht, weil der Anwender ja nur sagt bei mir auf der Uhr steht aber 13Uhr, Offset „Zeitzone“ kenne ich nicht.
In dem Fall sagt der Anwender um 13Uhr hatte ich einen Fehler und der Supporter kann genau in der Zeit im Log nachschauen, ohne Umrechnung.
Es wäre vielleicht auch denkbar wie folgt, vorzugehen: 1985-04-12T23:20:50+01:00
Damit könne man vielleicht zwei Fliegen mit einer Klappe schlagen. Ich recherchiere gerade mal etwas mehr dazu.
Grüße
WirCom
danke für das schnelle Feedback. Das ist natürlich eine Möglichkeit. Die Abteilung B sagt aber. Naja…das stimmt schon, aber heute hatte ich vier verschiedene Supportfälle mit 4 verschiedenen Zeitzonen. Somit müsste 4x umgerechnet werden auf Supporter Sicht, weil der Anwender ja nur sagt bei mir auf der Uhr steht aber 13Uhr, Offset „Zeitzone“ kenne ich nicht.
In dem Fall sagt der Anwender um 13Uhr hatte ich einen Fehler und der Supporter kann genau in der Zeit im Log nachschauen, ohne Umrechnung.
Es wäre vielleicht auch denkbar wie folgt, vorzugehen: 1985-04-12T23:20:50+01:00
Damit könne man vielleicht zwei Fliegen mit einer Klappe schlagen. Ich recherchiere gerade mal etwas mehr dazu.
Grüße
WirCom
