Frage Sollten Server ihre Zeitzone auf GMT / UTC eingestellt haben? [geschlossen]


Für kleinere Läden, die nur eine oder wenige Seiten haben, mag das keine große Sache sein, aber für größere Organisationen bin ich neugierig.

Was sind die Vor- und Nachteile, wenn Sie alle / den größten Teil Ihres Servers in UTC haben? Es würde sicherlich bei der Berichterstattung und zentralisierten Protokollierung helfen. Auch mit Ereigniskorrelation für die Fehlerbehebung oder Sicherheitsüberwachung. Man müsste sich auch nicht so viele Gedanken über die Änderungen der Sommerzeit machen.

Ein Nachteil könnte sein, dass das Planen von automatisierten Ereignissen (z. B. Cron) etwas Zeit in Anspruch nehmen kann, wenn Sie möchten, dass etwas in der lokalen geografischen Zeit um "4 Uhr" ausgeführt wird. Für Unix-y-Rechner könnten Sie immer noch Benutzer in der lokalen Zeitzone haben, indem Sie "TZ" in / etc / profile setzen, aber für Windows-Benutzer, die RDesktop in einen Server (aus welchem ​​Grund auch immer), sind sie fest mit UTC?


22
2017-10-15 12:50


Ursprung


Es gibt einen ähnlichen (älteren) Thread, der bei Sage-Mitgliedern läuft: mailman.sage.org/pipermail/sage-members/2010/msg00592.html - adamo
Und natürlich, da du die Frage auch an sage-Mitglieder gestellt hast, den (neuen) Thread mailman.sage.org/pipermail/sage-members/2010/msg01194.html :) - adamo
UTC eine Zeitzone, um alle zu regeln ... - Jarrod Roberson


Antworten:


Wie bei den meisten Dingen "hängt es davon ab".

  • Sind alle Ihre Administratoren / Benutzer in derselben Zeitzone? Vielleicht wäre ihr TZ angemessen.
  • Funktionieren die Maschinen mit der lokalen Umgebung? Das lokale TZ könnte gut sein.
  • Werden alle Protokolle zur Analyse an einen zentralen Ort gezogen? UTC könnte dort helfen.
  • Kommunizieren die Maschinen so miteinander, dass die Zeit zählt? UTC kann dazu beitragen, dumme Unstimmigkeiten zu vermeiden.
  • Hat der Betriebssystemanbieter (eher für Netzwerkgeräte) einen Vorschlag? Berücksichtige das.
  • Wird DST dich nerven? Verwenden Sie UTC.
  • Was wird deiner Meinung nach dein Leben erleichtern? Verwende das.

Ich habe alle Optionen (lokal, UTC, beliebig, aber konsistent) gewählt und bevorzuge die "lokale Zeit für das Heimarbeitsplatz für alle Maschinen", da dort die Systemadministratoren und Benutzer waren, obwohl die Maschinen auf der ganzen Welt verstreut waren .


19
2017-10-15 13:41



Gut gemacht - ich würde ein paar weitere Kriterien hinzufügen. 1) Wenn Sie Support-Organisationen in mehreren Zeitzonen haben, wird UTC überall wahrscheinlich Verwirrung vermeiden (in diesem Fall wird alles, was auf die Zeitzone "Home Office" eingestellt ist, nur dazu dienen, Leute in anderen Büros zu irritieren, ganz zu schweigen von der Verwirrung wenn DST eintritt. 2) Wenn Sie mit internationalen Anbietern wie Telekommunikationsanbietern zu tun haben, arbeiten viele von ihnen in UTC; Wenn Sie die Zeitstempel in Ihren Protokollen nicht konvertieren, wenn Sie sie senden, sparen Sie viel Zeit. - Murali Suriar
Ich habe über verschiedene Zeitzonen mit verschiedenen Servern gearbeitet. Wir hatten ernsthafte Probleme mit einem Projekt, bei dem Daten mit der Zeitzone des Servers gespeichert wurden, die auf DST und GMT eingestellt war. Nicht einfach zu beheben. Nicht einfach. UTC ist dein Freund :) - John Hunt


Wir setzen alles auf GMT, es vereinfacht die Korrelation von Protokolldateien zwischen Systemen.

Aber ich denke, wir sollten Zeitzonen fallen lassen, und alle benutzen GMT für alles.


6
2017-10-15 16:25





Wie andere gesagt haben, hängt es davon ab. Eine sehr große Gruppe mit langwierigen und weitreichenden Erfahrungen in dieser Angelegenheit hat gewirkt. Die Gruppe sind die Streitkräfte auf der ganzen Welt und sie benutzen UTC (GMT).

Eine andere Sache zu beachten. Wenn diese Systeme Anwendungscode unterstützen, müssen Sie wissen, ob die Anwendungen zeitzonenabhängig sind. In einigen Programmierforen, an denen ich teilnehme, schlage ich vor, dass das Datum / die Uhrzeit immer in UTC in der Datenbank gespeichert wird und dem Endbenutzer die Möglichkeit gibt, wie er das Datum / die Uhrzeit sieht.


3
2017-10-19 12:34





Ich arbeite für eine sehr große Hosting-Firma und wir haben Rechenzentren weltweit. Im Allgemeinen setzen wir die Maschinenzeit auf die lokale Datencenterzeit und verwenden dann die Zeitzone, in der sich alle unsere Supportmitarbeiter befinden, als die universelle Zeit, zu der Dinge konvertiert werden, wenn Tools usw. verwendet werden.

Wie andere gesagt haben, gibt es keine richtige Antwort, aber das ist die Methode, die wir verwenden :)


2
2017-10-15 15:09





Die Richtlinie besagt, dass alle Maschinen auf ihre lokale Zeitzone (d. H. Physischen Standort) synchronisiert werden. Das einzige Ding, das schwierig ist, korreliert Ereignisprotokolleinträge (windows machiens), da die Zeit nlocal gegeben wird - die meisten anderen Protokolldateien schreiben die Zeit in UTC irgendwie.

aber für Windows-Benutzer, dass RDesktop   in einen Server (aus welchem ​​Grund auch immer),   hängen sie fest an UTC?

Nicht ganz sicher, aber ich denke ja - die Zeitzone ist logisch eine Maschinenebene Einstellung.


1
2017-10-15 13:14





Wir haben Maschinen physisch in einer Zeitzone, die wegen der Anwendung, die sie unterstützen, für 3 Stunden voraus gesetzt werden.

Wir haben auch Entwickler, die Software entwickeln, die eine Synchronisation von unter fünf Sekunden zwischen Servern erwartet, Entwickler, die implizit auf AD-Zeit für die Synchronisation angewiesen sind und sich nicht darum kümmern, Fehlerprüfungs- oder -behandlungsroutinen für nicht synchronisierte Fälle zu schreiben und zu bestätigen dass die nachfolgenden Fehler die Admins dafür verantwortlich sind, dass sie die Netzwerkzeit nicht auf den Standard bezogen haben, den sie sich vorstellen.

Tu nicht, was wir getan haben. Es wird dich nur bitter machen.


1
2017-10-15 17:11





Um die Diskussion noch zu verstärken, haben wir Büros auf der ganzen Welt verteilt und jede von ihnen hat ihre eigenen Web-, Anwendungs- und Datenbankserver, mit verschiedenen Anwendungszweigen für jede von ihnen, so dass die lokale Zeitzone eine gute Idee ist sprechen landesweit. Für US-Server gehen wir in Richtung Central Time für alle Standorte, die mit unserem Hauptdatencenter übereinstimmen, da die Verwendung unterschiedlicher Zeitzonen für App-Server und Datenbanken den Entwicklern Schwierigkeiten bereitet.


1
2017-09-27 16:15