ubuntuusers.de

Gute Tag an die Community ☺

Ich beschäftige mich gerade mit dem Thema Zeitzonen bei Betriebsystemem... und entweder stelle ich mich dumm an, oder die Sache ist wirklich nicht ganz so trivial.

Ich stelle einfach mal die Frage und dann kommen wir zum Szenario warum ich frage: Liesst Linux Software allgemein (nicht der Kernel selber) die Software zeit Selber oder die RTC ? Bestes bsp: RRDtool - werden die Graphen anhand der Systemzeit erstellt oder anhand der RTC ?

Frage deswegen so allgemein, wegen besagten Szenario:

Gehen wir davon aus ich betreibe einen Linux Server auf den eine Datenbank läuft und Zeiten Protokolliert werden, auf den greifen Leute aus mehreren unterschiedlichen Zeitzonen zu (Per Webinterface).

Ich weiss: Datenbanken sind ziemlich sensibel was Uhrzeit anbelangt und das man die RTC nach IMMER nach UTC stellen sollte - um Sommer und Winterzeiten zu umgehen und nicht plötzlich (zb systemd) zurück synchronisieren muss oder so spaßige sachen -.-

aber jetzt kommts: Was ist mit der Systemzeit (die normalerweise mit Date abgerufen wird) - sollte ich die auch nach UTC stellen oder nach meiner zeitzone oder wie ? Gehen wir davon aus ich stelle die Systemzeit auch nach UTC dann habe ich das Sommer und Winterzeit Problem nicht mehr, aber mir wird im Webinterface ja ne falsche Uhrzeit angezeigt...

Ich hoffe ihr könnt mir folgen ? Will halt nicht jedes mal die uhrzeit umstellen muessen oder probleme mit der Datenbank kriegen weil die Zeit plötzlich "rückwärts geht".

ich finde das Thema sehr berechtigt, bekanntlich ist Zeit ja Geld / schöpferischen Geldfluss bzw Schwingung. t = $ / ( $/t)

Also es gibt ja im PC diese kleine Batterie für das Bios, da läuft die Interne PC Uhr.

was die so sagt kannst du dir mal anzeigen lassen in der Konsole:

hwclock --show

die läuft bei mir zB nach UTC.

Da ich in Deutschland sitze und hier die Menschen nach der "normalen" zentraleuropäischen Zeit im wahrsten Sinne des Wortes "ticken" richte ich mich auch nach dieser. Deshalb habe ich auf meinen Systemen die Zeitzone eben auf Zürich (gefällt mir besser als Berlin) gesetzt.

auch interessant die Ausgabe von

timedatectl

und

date

bei einem Server würde ich immer alles in UTC speichern, und dann können andere Module diese Daten weiterverarbeiten, um diese bei uns in Deutschland mit der Verschiebung und ggf So/Wi Zeit Umstellung richtig angezeigt werden, zB auf Webseiten, wo dann geschaut wird, von wo der Besucher kommt welchem Land und dementsprechend rechnet der Server es um und zeigt es dem Besucher so an wie seine lokale Zeit läuft sodass er nicht mit der Zeit rumrechnen muss wie ein Pilot, aber auf dem Server in der Datenbank alles UTC.

mM

Mist3rT schrieb:

aber jetzt kommts: Was ist mit der Systemzeit (die normalerweise mit Date abgerufen wird) - sollte ich die auch nach UTC stellen oder nach meiner zeitzone oder wie ?

Du stellst da bitte überhaupt nix sondern läßt das bitte einen NTP Client deiner Wahl erledigen.

Siehe https://en.wikipedia.org/wiki/Unix_time https://de.wikipedia.org/wiki/Unixzeit

Es gibt einen Zeitstempel (Sekunden seit 1-1-1970 00:00 UTC) und der ist weltweit gleich.

Das kannst du dann je nach Gusto in eine x-beliebige Zeitzone deiner Wahl umrechnen lassen.

aber mir wird im Webinterface ja ne falsche Uhrzeit angezeigt...

Schlecht programmiert, falsche Zeitzone konfiguriert oder beides.

Will halt nicht jedes mal die uhrzeit umstellen muessen oder probleme mit der Datenbank kriegen weil die Zeit plötzlich "rückwärts geht".

Wenn du tatsächlich von Hand an der Uhr drehst, gehen die Probleme erst richtig los. Dann hast du eine Datenbank voller falscher Zeitstempel und die bekommst du nicht mehr raus.

Naja nicht daran rum fummeln ist gut - NTP ist bei allen Servern noch lange nicht standard und man rät auch von NTP daemon ab (jedenfalls für clientseitige NTP anfrage - weil angreifbar) und allein schon das es selbst im business Umfeld noch spezielle Systemkonfigurationen gibt und daher wird bei den meisten Installationen noch gefragt ob localtime oder UTC verwendet werden soll (natürlich auch systemzeit etc) und um mehr geht es hier auch nicht.

Beides beantwortet leider meine frage auch nicht ganz: Zwar: Wie konfiguriert man am besten die Serverzeit am besten sodass man a) kein hassle mit Uhrzeiten in Datenbanken etc hat und wegen der Zeitumstellung etc. und b) das die Leute die sich drauf verbinden trotzdem ihre lokale zeitzone die Sie bei sich eingestellt haben, sehen (und nicht UTC Zeit sehen).

Hab auch nochmal über meine erste Eingangsfrage nachgedacht: Denke mal das Software eig. immer die Betriebsystem Zeit ausliesst und nicht die RTC ? Alles andere macht auch wenig sinn, da es ja Systeme ohne Bios somit ohne RTC daher kommen (siehe ARM), denke da waere es dumm wenn linux pakete die Hardwarezeit auslesen würden, oder sehe ich das falsch ?

alles kommt in den Server als Zeitstempel UTC.

Dh alle Datum/Uhrzeiten die gespeichert werden sollen werden zuvor in UTC umgerechnet.

Und dann immer wenn ein Datum/Uhrzeit abgefragt wird steht es in UTC in der Datenbank, und dann von dort rechnest du es weiter um. in der Datenbank ist aber alles UTC.

da kann nix passieren weil die Daten sind sicher in UTC abgespeichert, da gibts keine unterschiedlichen Möglichkeiten.

So wie Gold im Tresor, und wenn dich jemand fragt wieviel Yen, Dollar, Euro drin sind rechnest du es für die jeweils entsprechend um. Ebenso wenn du dann Fremdwährungen annimmst tauscht du sie immer erst in Gold und packst sie dann in den Tresor. Dann ist alles safe.

Das Gold steht im Vergleich für das UTC und die ganzen Währungen für die vielen Zeitzonen mit und ohne DST Umstellung usw

OK Danke, heisst also (nur damit ich das richtig verstehe):

Anhand eines Samba Servers (ob das Sinn macht erstmal egal, geht nur ums Prinzip): Samba Server selber auf UTC eingestellt, User a) aus Californien mit seiner eingestellten Zeitzone, Benutzer B) aus Deutschland mit seiner Zeitzone.

Nutzer A) Scheffelt Dateien auf den Server und Nutzer B) Liesst das Verzeichnis - dann sieht Nutzer B) seine Uhrzeiten also nach seiner Zeitzone (Europe/Berlin als bsp). Würde ich jetz remote auf den Server gucken würde ich dann alle Zeitstempel als UTC sehen richtig ?

Wenn ja, heisst das im umkehrschluss: Ich muss /etc/adjtime nach utc (nicht localtime) stellen und date bzw timezone ebenfalls auf UTC...

du musst nicht die ganze Maschine auf UTC stellen, damit Zeitstempel in UTC gespeichert wird.

Du kannst alles auf MEZ haben und dennoch werden die Stempel in UTC gesetzt.

Dh.

Jemand aus Californien speichert etwas auf den Server. Das wird als Zeitstempel in UTC gespeichert. Das ist universell. Dann will jemand aus Deutschland wissen, wann dieser Serverzugriff war. Dazu wird für Ihn dieser Sekundenwert umgerechnet in seine Zeit.

Und gleichzeitig kann aber auch auf diesem PC wo das Samba ist ein Linux laufen dass unten rechts eine Uhr mit deutscher Zeit anzeigt. UTC ist das Uhrwerk, und dann kann man diese universelle Zeit unterschiedlich anzeigen lassen.

Ok und das ist aktueller standard in Linux und in den großen software Paketen (Samba und was weiss ich) ? Kann also auf dem Server theoretisch wild die Zeitzonen wechseln ohne das die Zeitstempel verändert werden und sie werden auch immer in UTC gespeichert ?

Ist das auch Standard in den Einstellungen oder muss man irgendwas Einstellen / Beachten ?

EDIT: Synchronisieren NTP Zeitserver auch immer nach UTC ? Also wenn ich jetzt localtime von Berlin auf was anderes (zB. Ägypten) stellen würde... dann ist es egal mit welchen Zeitserver ich theoretisch synchronisiere, unabhaengig von der Zeitzone ?

Randfrage: Gibt es gründe die RTC neu zu synchronisieren, oder reicht einmal und gut ist ? (Gesetz dem fall die CMOS - bei nen x86 board is nicht leehr, sonst logisch) ?

Ja genau der kann wild die Zeitzonen wechseln...

Emails werden ja auch immer mit UTC verschickt und bei dir steht die deutsche Uhrzeit im Postfach und beim Adressat in Californien seine WestküstenAmiZeit

Die Hardware Bios Uhr wird durch das NTP mitgesynct, allerdings oft auf UTC, und das System zeit dann eben zB MEZ an.

Zur NTP Frage: https://de.m.wikipedia.org/wiki/Network_Time_Protocol

„Die Zeitstempel im NTP sind 64 Bits lang. 32 Bits kodieren die Sekunden seit dem 1. Januar 1900 00:00:00 Uhr, weitere 32 Bits den Sekundenbruchteil. Auf diese Weise lässt sich ein Zeitraum von 232 Sekunden (etwa 136 Jahre) mit einer Auflösung von 2−32 Sekunden (etwa 0,23 Nanosekunden) darstellen.“

(Wusste ich auch noch nicht)

Mist3rT schrieb:

Randfrage: Gibt es gründe die RTC neu zu synchronisieren

Quarzuhren haben eine begrenzte Ganggenauigkeit, die deutlich schlechter als das ist, was NTP liefern kann. Die RTC dient als Stütze, damit dein Server beim Start nicht denkt, dass es der 1. Januar 1970 ist, aber genauere Zeitstempel wirst du erst dann haben, wenn du eine bessere Zeitquelle nutzt. Neben NTP gibt es ja auch noch in den meisten Regionen die Möglichkeit Funkzeitsignale zu nutzen, also z.B. hier in Europa DCF77 - wenn man will kann man das auch als Quelle für einen eigenen NTP-Server nutzen: http://www.raspberry-pi-geek.de/Magazin/2014/01/Raspberry-Pi-als-Funkuhr-und-NTP-Stratum-1-Zeitserver (wenn man das nicht als Lernprojekt macht, kann man sich natürlich entsprechende Geräte von kommerziellen Anbietern hinstellen, die dann auch noch eine Reihen von sinnvollen Zusatzfeatures wie Temperaturstabilisierung bieten).

Ok Danke an euch allen, sind halt speziellere fragen die (denke ich) so nicht im Wiki 1:1 zu finden gewesen wären, aber jenachdem was hier für Antworten bei rum kommen muss ich die Server config anpassen für das neue Projekt und ja da sollte Zeit so genau wie moeglich sein 😉

Ja genau der kann wild die Zeitzonen wechseln...

Hab vorhin mal nen kleinen kurztest auf ein anderen Server gemacht - da ging das nicht ohne weiteres, aber das kann auch andere Ursachen haben. Mache heute abend mal nen genaueren versuch in einer Test-Umgebung, sollte da noch was schief laufen kann ich ja nochmal fragen...

Generell bin ich wie folgt auf das Thema gekommen: Durch eine Serverwartung ist mir das erste mal ein System unter die Hand gekommen was vollständig UTC eingestellt war. Also nicht nur RTC auf utc gestellt sondern auch Betriebsystemzeit sowie Zeitzone... Wenn doch eh sämtliche Zeitstempel aus UTC erzeugt werden (also die Timezone mit offset ermittelt wird) - Wieso stellt man dann alles samt Zeitzone auf UTC ? Gibs bestimmte einsatz Szenarieren wo das relevant ist, oder wie üblich: "menschlicher Irrglaube" ?

Der Vorteil Systeme mit UTC laufen zu lassen ist, dass man von der Lokalzeit unabhängig ist. Egal wo du gerade auf der Welt bist hast du die selbe, praktisch monoton ansteigende Zeit auf deinem Server und sparst die die Sonderfallbehandlung bei der Zeitumstellung. Bei Luft- und Schiffahrt nutzt man die UTC, um Fehler oder Missverständnisse durch Zeitzonenumrechnungen zu vermeiden.

Mit einem in Lokalzeit laufenden Cron kann man zum Beispiel bei der Umstellung von Sommer- auf Winterzeit viel Spaß haben, denn dann hast du alle Zeiten zwischen 2 und 3 Uhr zwei mal in der Nacht...

Mist3rT schrieb:

NTP ist bei allen Servern noch lange nicht standard

Eigentlich doch schon. Das gibts nicht erst seit gestern.

und man rät auch von NTP daemon ab (jedenfalls für clientseitige NTP anfrage - weil angreifbar)

Du musst keinen Zeitserver für andere bereitstellen.

daher wird bei den meisten Installationen noch gefragt ob localtime oder UTC verwendet werden soll (natürlich auch systemzeit etc) und um mehr geht es hier auch nicht.

localtime macht nur Sinn, wenn noch Windows im Spiel ist, aber es spielt auch sonst keine Rolle, ob du in der hwclock die UTC oder localtime hinterlegst. Vorausgesetzt, beim Abfragen der hwclock (Reboot) weisst du noch, was es mal gewesen sein soll, sonst geht die Uhr eben direkt mal komplett falsch.

Aber danach musst du sowieso wieder einen Zeitserver deines Vertrauens fragen, wieviel Uhr es eigentlich gerade wirklich ist. Mit Initramfs wäre die Zeitsynchronisation möglich, noch bevor man überhaupt irgendein Dateisystem mountet. Leider liegt die Priorität woanders - den Bootvorgang eine Sekunde schneller abzuschließen ist scheinbar wichtiger.

a) kein hassle mit Uhrzeiten in Datenbanken etc hat und wegen der Zeitumstellung etc.

Die Zeit an sich muss stimmen und das schaffst du nur indem du dich mit der Welt auf eine Zeit einigst (NTP).

Deine Datenbanken, Programme etc. müssen sich die Unixzeit (oder sonst einen Standard wie Zeit inklusive Zeitzonen-Offset a la date -Is → 2018-03-22T11:26:05+01:00) merken und nicht irgendein Lokalzeug ohne dazu zu sagen, lokal zu was.

Das einzige was du konfigurierst ist die Zeitzone und die kannst du jederzeit ändern, das ist dann nur Optik.

b) das die Leute die sich drauf verbinden trotzdem ihre lokale zeitzone die Sie bei sich eingestellt haben, sehen (und nicht UTC Zeit sehen).

Dazu muss dein Programm den Leuten eben eine Einstellmöglichkeit bieten oder JavaScript fragen in welcher Zeitzone die sich so bewegen.

Probleme fangen an wenn die Uhr an sich falsch geht. Es gibt nur eine Zeit (Unixzeit) die weltweit gleich ist, völlig unabhängig in welcher Zeitzone du bist. Geht die Zeit falsch bekommst du das nicht mehr ohne weiteres hin.

Bei Digitalkameras gibts das Problem, SD-Karte gewechselt? Einmal an der Batterie gewackelt, und die Kamera vergisst die Uhrzeit / macht eine Zeitreise und alle Fotos die ab dann geschossen werden sind plötzlich 30 Jahre alt oder so.

Der einzige Weg das zu korrigieren ist dann bei wenigstens einem Foto zu wissen, wann genau es geschossen wurde... dann kannst du die Zeitstempel in allen Fotos ab dem auftreten des Uhrproblems um das bekannte Delta nachjustieren.

Wenn du falsche Zeitstempel in deiner Datenbank hast, müsstest du das auch so machen. Irgendwo eine Referenz haben, um wieviele Sekunden dein Zeitstempel falsch ist, welche Einträge den gleichen Fehler falsch sind und dann diese alle korrigieren.

Das hat aber mit Zeitzone nichts zu tun.

seahawk1986 schrieb:

Mit einem in Lokalzeit laufenden Cron kann man zum Beispiel bei der Umstellung von Sommer- auf Winterzeit viel Spaß haben, denn dann hast du alle Zeiten zwischen 2 und 3 Uhr zwei mal in der Nacht...

Stimmt daran hab ich ja gar nicht gedacht, sollte ich mir merken 😉

Ansonsten nochmal ein Danke an alle, die sich hier beteiligt haben. Hab soweit keine weiteren fragen mehr und @rafi: Die Samba Testumgebung verlief auch ohne Probleme und es verhielt sich so wie du beschrieben hast.

Für die Nachwelt: Bitte lest euch den ganzen Thread durch und nicht nur die "Lösungsantwort" - Zusammenhang hier ist wichtig (Für die Leute die nur die Lösung lesen) 😉

Ansonsten euch noch ein schönes Wochenende ☺