Falsche Uhrzeit unter Windows – Leserbeobachtungen

[English]In Windows scheint es in letzter Zeit Probleme mit der Synchronisierung der Internetzeit zu geben. Nach einem Problem mit der automatischen Sommerzeitumstellung, Ende März 2020, noch ein kurzer Nachtrag mit Leserrückmeldungen zum Thema.


Anzeige

Ende März 2020 hatte ich im Artikel Windows 10: Problem bei der Sommerzeitumstellung 2020? ja über Probleme mancher Nutzer mit der automatischen Zeitumstellung durch Windows berichtet. Nun noch ein Nachtrag in Form zweier Nutzermeldungen, die mir ihrer Beobachtungen schilderten. Ich stelle die Beobachtungen einfach mal so ein, wie sie mir berichtet wurden.

Merkwürdiges Verhalten von Windows 7

Blog-Leser Wilfried L. arbeitet noch mit Windows 7 und ist durch den obigen Beitrag animiert worden, seine Beobachtungen mitzuteilen. Dazu schreibt er:

angesichts Ihres Beitrags zur Umstellung auf Sommerzeit und der vielen Kommentare will ich doch noch auf meine rätselhaften Beobachtungen zur eine Stunde nachgehenden Uhr bei Windows 7 (Home Premium SP1 32bit) hinweisen. Vielleicht besteht ein Zusammenhang.

Dank Armbanduhr verzichte ich eigentlich auf die Anzeige der Uhrzeit am Rechner, habe sie aber jetzt seit Dezember 2019 längere Zeit beobachtet, nachdem mir falsche Zeiten in Mail-Anzeigen aufgefallen waren. Manchmal wechselte die Zeit während einer Sitzung nach einer oder mehreren Stunden zur korrekten, auch mal nach einem Update von Windows, nach Neustart konnte sie, musste aber nicht, wieder falsch sein – kein System zu erkennen.

Zeitzone, Wechsel zwischen Sommer- und Winterzeit und Synchronisation über das Internet mit einem Zeitserver waren korrekt eingestellt. Wechsel des Zeitservers halfen nur vorübergehend.

Die Uhr ging im Winter eine Stunde nach, und dabei blieb es nach Beginn der Sommerzeit. Noch verrückter: nach Deaktivierung der Synchronisation mit einem Zeitserver und manueller Einstellung ging die Uhr am nächsten Tag gleich zwei Stunden nach, und dies wiederholte sich auch, wenn unter Windows zwischenzeitlich keine Internetverbindung bestand. Unter Linux (Dual Boot) ist die Zeit korrekt. Ein anderer, wenig genutzter, Rechner scheint nicht betroffen. Es muss also Windows auf dem Rechner verrückt spielen.

Bereits am 24.3.18 (einen Tag vor Umstellung auf Sommerzeit) musste ich so etwas beobachten bei einer fehlerhaften Timer-Aufnahme. Bei den Zeiteinstellungen wurde kurz darauf behauptet, die Zeit sei (planmäßig) am 25.3.18 um 8:19 synchronisiert worden, und "Jetzt aktualisieren" führte zur Meldung: "Fehler beim Ermitteln des Status der letzten Synchronisierung. Die Schnittstelle ist unbekannt." Daraufhin hatte ich den Zeitserver damals erfolgreich umgestellt von time.windows.com auf time.nist.gov.

Insgesamt scheinen die Zeitserver von Microsoft immer mal wieder Probleme zu bereiten.

Rückmeldung von Andi

Auch von Blog-Leser Andi O. erreichte mich eine Rückmeldung zum Thema Zeitsynchronisation unter Windows. Auch Andi bezieht sich auf meinen obigen Artikel und schreibt.

In den Kommentaren [zu obigem Artikel] hatte es mal geklappt, mal aber auch nicht. Das hab´ ich mir zum Anlass genommen, und mal geschaut, wie der Stand der Dinge in meiner [Windows 10] 1909 ist.

Ich habe den Starttyp des Zeitgebers eingestellt, den Rechner neugestartet, und dann versucht, mit der Eingabeaufforderung den Zeitgeber zu starten.

Anmerkung: Mein Konto für den Test war Administrator. Wenn der Starttyp des Zeitgebers auf "Deaktiviert" steht, dann kommt ´ne Fehlermeldung und der Zeitgeber verweigert seinen Dienst. Siehe Screenshot "Fehlermeldung Zeitgeber deaktiviert".

Bei "Manuell" sieht es anders aus. Man könnte denken, bei "Manuell" kann der Zeitgeber immer starten. Dem ist aber nicht ganz so. Öffne ich die Eingabeaufforderung über das Kontextmenü "Als Administrator", startet der Zeitgeber, siehe Screenshot "Zeitgeber manuell cmd als Administrator".

Zeitgeber manuell cmd als Administrator

Öffne ich die Eingabeaufforderung aber normal, wird der Zeitgeber blockiert. Siehe Screenshot "Zeitgeber manuell cmd normal".

Zeitgeber manuell cmd normal

Bei der Windows 10 Version 1909 ist es also so, dass beim Zeitgeber der Starttyp "Manuell" von der Benutzerkontensteuerung blockiert wird. Synchronisierung geht also nur, wenn man sie selber manuell ausführt, oder wenn man einen lokalen Benutzer hat.

Ähnliche Artikel:
Windows 10: Problem bei der Sommerzeitumstellung 2020?
Windows 10: Probleme mit der Zeitsynchronisation – Teil 1
Windows 10: Probleme mit der Zeitsynchronisation – Teil 2


Cookies blockieren entzieht uns die Finanzierung: Cookie-Einstellungen

Dieser Beitrag wurde unter Windows abgelegt und mit verschlagwortet. Setze ein Lesezeichen auf den Permalink.

10 Antworten zu Falsche Uhrzeit unter Windows – Leserbeobachtungen

  1. Dalai sagt:

    Beide Phänomene sind erklärbar.

    Die erste Sache mit dem Win7 ist simpel: Linux nimmt die in der Hardware-Uhr gespeicherte Zeit standardmäßig als UTC an, Windows nimmt aber immer lokale Zeit an. Der Unterschied zwischen UTC und lokaler Zeit ist eben eine Stunde (MEZ) bzw. zwei Stunden (MESZ). Wenn man also zwischen Linux und Windows wechselt, ist es logisch, dass die Uhr immer verstellt wird bzw. es eine Weile dauert, bis sie korrigiert wird.

    Will man das Hin- und Herschalten der Uhr verhindern, muss man entweder Linux so einstellen, dass es in der Hardware-Uhr ebenfalls lokale Zeit annimmt, oder Windows sagen, dass es UTC annehmen soll. Für beide Fälle gibt es ausreichend Anleitungen im Netz, unter anderem bei wiki.ubuntuusers.de (Suche nach Systemzeit).

    Die zweite Sache ist ebenfalls logisch: Deaktivierte Dienste können nicht gestartet werden, von keinem Nutzer oder Admin. Ist einfach so, egal womit man versucht, den Dienst zu starten. Das MMC Snap-In services.msc bietet das Starten eines deaktivierten Dienstes deswegen auch gar nicht an (ausgegraut). Und zum anderen wird aus nachvollziehbaren Gründen einem Benutzer ohne Adminrechte das Starten von Diensten mit manuellem Starttyp verweigert – hier im Falle einer als Nutzer laufenden CMD. Fazit: Will man deaktivierte Dienste starten, braucht man zuerst Adminrechte, muss dann den Starttyp des Dienstes ändern und erst dann kann der Dienst gestartet werden. Das war übrigens schon immer so, selbst unter Win2k, und seit Vista sorgt die UAC für das Entfernen der Adminrechte auf fast allen Prozessen.

    Das zweite Problem ließe sich übrigens ebenfalls lösen, indem man den Starttyp des w32time auf Automatisch (oder Automatisch Verzögert) stellt.

    Ich hoffe, das bringt etwas Licht ins Dunkel.

    Grüße

    • 1ST1 sagt:

      Absolut richtig. Die beiden "Fehlerbeschreibungen" sind ein Tiefpunkt dieses Blogs.

      • Günter Born sagt:

        Auch wenn Corona – einfach eine Runde nach draußen spazieren gehen ….

        • 1ST1 sagt:

          Ich bin das Wochenende sogar über 150 km Rad gefahren. Wäre gestern das Wetter nicht so schlecht gewesen, wären es sicher über 200 geworden. Aber das unterschiedliche Zeitverhalten von Windows und Linux, genau wie dass man als Nicht-Administrator keine Dienste starten kann, schon garnicht deaktivierte Dienste, das sind eben Basics, die man Microsoft nicht in die Schuhe schieben kann.

          • Martin W. sagt:

            @ 1ST1
            Jetzt mach Dich mal ein bisschen locker!
            1. Auch wenn Du solche Probleme offenbar per SSH von Deinem Fahrradcomputer aus bei Kilometer 144 lösen kannst, heißt das nicht, dass das jeder kann.
            2. Auch wenn es hier manchmal MS-kritisch zugeht, so geht es dennoch in erster Linie darum Probleme zu lösen und nicht um Schuldzuweisungen.
            3. Auch als erfahrener IT-ler hängt man manchmal viel zu lange an Problemen aus der Kategorie "Basics", man sieht den Wald vor lauter Bäumen nicht. Da sind gerade solche Artikel wie dieser hilfreich.
            4. Auch wenn in vielen IT-Foren ein eher rauer Ton herrscht, so ist es doch gerade wohltuend, dass es hier in Günters Blog meist freundlich und konstruktiv zugeht. Es gibt keine "dummen Fragen". Lass es bitte dabei!

    • Günter Born sagt:

      Kurze Rückmeldung von Blog-Leser Winfried:

      danke für die Einstellung meiner Frage in Ihren Blog. Der Kommentar von Dalai hat mein Problem sofort gelöst, habe Windows jetzt entsprechend umgestellt, Dank auch an ihn.

      Daß das aktuelle Problem mit einem unterschiedlichen Umgang von Windows und Linux mit der Uhrzeit zusammenhängen muß, hatte ich bei weiteren Experimenten und Blick ins BIOS-Setup inzwischen erkannt. (Eine leere Backup-Batterie dagegen äußert sich bei Zeit und Datum anders.)

      Aber egal, ob Windows oder Linux, ich kann so viele Bücher lesen wie ich will, im Alltag helfen am Ende nur Tips von Dritten. Was für mich als isoliertem Privatnutzer aber bedeutet, daß ich mehr Zeit mit Recherchen und Experimenten verbringe als mit der praktischer Nutzung des Rechners – ist doch irre. Umso unverzichtbarer ein Blog wie der Ihre.

  2. Ärgere das Böse! sagt:

    "…Zeitzone, Wechsel zwischen Sommer- und Winterzeit und Synchronisation über das Internet mit einem Zeitserver waren korrekt eingestellt. Wechsel des Zeitservers halfen nur vorübergehend…"
    Die Batterie auf dem Motherboard hast Du auch schon mal gewechselt? Ich hatte das Problem auch schon, und mit dem Wechsel der Batterie war es weg.

    Ich habe noch den Kommentar von Dalai gelesen, der das Problem erklärt, somit meine Lösung für diesen Fall nicht zum Tragen kommt. Das mit der Batterie führt oder kann zu Problemen mit der Zeitanzeige führen.

  3. Zeitgeber0815a sagt:

    >"Insgesamt scheinen die Zeitserver von Microsoft immer mal wieder Probleme zu bereiten."

    Kann sein, aber ich aktualisiere über die PTB, von daher liegt der Fehler im OS. Wie kann es sein, dass hier Nutzer Detektive spielen müssen? Noch immer keine Antwort aus Redmond, im ernst Microsoft?

  4. Thorky sagt:

    "Allzeit Atomzeit" (https://www.netzwelt.de/download/4687-allzeit-atomzeit.html)
    Bei mir aktualisiert AzAz drei Minuten nach Systemstart im Hintergrund, hält diesen also nicht auf, und beseitigte dabei zuverlässig den Sommerzeitfehler.

  5. Olaf Eitner sagt:

    Da sprechen Sie trotzdem ein sehr wichtiges Thema an. :-! Zeitsensitive Prozesse, wie Kerberos und Co., brauchen richtig gehende Zeiten in einem Netzwerk. Wusstet ihr z.B, dass die Fritz!Box, wenn DSL nicht da, eine Zeit vom 01.01.1970 ins interne Netz schickt, wenn man sie als Intranet-Zeitquelle angibt. Ich grübelte vor einiger Zeit eine kleine Ewigkeit, warum bei mir die Anmeldung an bestimmte Intranetzknoten nicht mehr funktionierte. Bis ich dann mal einen Blick auf die PC-Zeiten warf. Ich habe auch schon AVM danach gefragt. Nun versuche ich mir einen eigenen kleinen Zeitserver (batteriegepufferten) zusammenzubasteln, den ich einfach neben meinem Router in die Ecke stelle und als Zeitquelle im Intranet zur Verfügung stelle. Ich bin nämlich faul😁 und will so wenig wie möglich mit Logins und Passwörtern arbeiten… 🙄😁

Schreibe einen Kommentar zu Thorky Antworten abbrechen

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert

Hinweis: Bitte beachtet die Regeln zum Kommentieren im Blog (Erstkommentare und Verlinktes landet in der Moderation, gebe ich alle paar Stunden frei, SEO-Posts/SPAM lösche ich rigoros). Kommentare abseits des Themas bitte unter Diskussion.