Anzeige
Anzeige

Am Puls von Microsoft

Anzeige

Sommerzeitumstellung 2019 mit Version 1809

Nur die Einigung auf Sommer oder Winter Zeit ist noch nicht ganz klar.
Zum Vergrößern anklicken....
Oder irgendetwas dazwischen und für jedes Land anders - jedenfalls eine "Lösung", die sich keiner gewünscht hat! :eek:
 
Anzeige
Können wir nicht beeinflussen. Politiker legen das fest. Es wird eine Abstimmung geben, aber letztendlich machen die was sie wollen.
Hauptsache die machen meine Funkuhren nicht kaputt. :ROFLMAO:
 
BlackNinja2017 schrieb:
Der Defender kann die Zeitabfrage auch blocken mit der Ransomware Einstellung.
Da wird jede Veränderung am System geblockt.
Zum Vergrößern anklicken....

Der Ransomware-Schutz des Defenders verhindert den Zugriff von Programmen auf die persönlichen Ordner des Benutzers. Weder hat er etwas mit dem Schutz des Systems selber zu tun, noch mit Netzwerkverkehr.

PeteM92 schrieb:
Stimmt nur im Prinzip. Die standardmäßig eingestellten Zeitserver time.windows.com bzw. time.nist.gov stehen in den USA. Demzufolge unsicher ist die Laufzeit des Signals. Da wird die Uhrzeit schon mal fast eine Sekunde falsch eingestellt.
Zum Vergrößern anklicken....

Meinst du wirklich, dass die Entwickler des NTP Protokolls sich nicht Gedanken über sowas gemacht hätten? NTP wurde zu Zeiten entwickelt, wo Bytes noch über fürchterlich langsame Leitungen tröpfelten. Natürlich wird so etwas innerhalb des Protokolls korrigiert.

"Die lokalen Abweichungen infolge der Latenzzeit der stochastisch bestimmten Übertragungswege werden durch Messverfahren der Paketumlaufzeit vom Server (Berkeley-Algorithmus) oder vom Client (Cristians-Algorithmus) kompensiert."
https://de.wikipedia.org/wiki/Network_Time_Protocol
 
Ich hatte auf einem System mit Version 1809 auch einen solchen Fehler. Die Systemzeit ging eine Stunde vor. Allerdings war der Rechner Samstag und Sonntag ganztägig im Standby bzw. Ruhezustand. Ließ sich einfach durch eine Neusynchronisation mit dem Zeitserver beheben.

Vermutlich ist das ein ähnliches Problem wie bei den Defender-Updates. Da wird an einer Stelle zweifach die Zeit umgerechnet und solange noch keine neue Zeit vom Zeitserver vorliegt, stimmt dann irgendwas nicht.

Es ist eben problematisch, wenn man sich im Betriebssystem nicht auf eine Zeit einigen kann, sondern unterschiedliche Komponenten mal mit Ortszeit, mal mit UTC arbeiten. In welcher Zeit die Hardware-Uhr läuft, ist dabei völlig nebensächlich. Derartige Probleme sind ja nicht nur auf Windows beschränkt, sondern die gibt es auch bei Linux. Aber solange die Programmierer sich nur beschweren, Zeitumstellungen, Schaltsekunden und -tage abschaffen wolle, statt endlich mal zumindest betriebssystemintern eine einheitliche Lösung schaffen, wird sich nie etwas ändern.
 
Bei CB hat jemand etwas zu diesem Thema gepostet, vielleicht hilft das ja:

Leutchen ... tut euch doch den Gefallen und setzt die RTC (real time clock, Echtzeituhr, BIOS-Uhr) auf all euren Rechnern auf UTC und teilt Windows dies mit einem Registry-Eintrag mit.

[HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\Control\TimeZoneInformation]
"RealTimeIsUniversal"=dword:00000001

Dann zeigt Windows bei korrekt eingestellter Zeitzone ganzjährig immer die richtige Zeit an, unterlässt die idiotische Umstellung der RTC auf "lokale Sommer-/Winterzeit" mit all ihren Folgen (wie man in diesem Thread mal wieder sieht) und updatet die BIOS-Uhr brav in UTC. Die RTC zählt dann endlich monoton aufwärts, wie man es von einer Uhr erwartet. Kein Zeitsprünge mehr. Praktisch jedes vernünftige, netzwerkfähige OS arbeitet schon immer so, nur Windows leider nicht.

Microsoft wurde jahrzehntelang gebettelt, dieses schräge Verhalten mit den Zeitsprüngen durch die Zeithaltung in lokaler Zeit endlich aufzugeben. Ab Windows 7 Patch irgendwas war Windows passabel dazu in der Lage, mit auf UTC laufender RTC umzugehen. Nutzt das! Leider ist die Voreinstelung von Windows noch immer das alte Verhalten mit der lokalen Zeit in der RTC.
Zum Vergrößern anklicken....

Quelle: https://www.computerbase.de/forum/t...-wird-falsch-angezeigt.1573562/#post-22493328
 
Zuletzt bearbeitet:
1809
Musste auch die Zeit manuell anpassen.
die Region war richtig und Sommerzeit auf AN.
Aber trotzdem musste ich manuell die Zeit eine Stunde vor stellen
 
Man kann die Urzeit auch im Uefi BIOS einstellen, dann stimmt es auch in Windows.
 
hatte diese Proleme auch. Hatte PTB Server schon seit XP , ab 1809 gind nichts mehr, bei verschiedenen anderen Zeitservern gings auch nicht.
Zurückgegangen auf "Time.windos.com" und schlagartig war Ruhe. Funzt wie's Donnerwetter. Warum, keine Ahnung, ist mir aber auch egal, es funktioniert.
 
PeteM92 schrieb:
Wenn man das ändern will, dann muß man statt
ControlSet
CurrentControlSet eingeben.
Zum Vergrößern anklicken....
"ControlSet" gibt es bei mir gar nicht.
Bei mir gibt es die beiden Schlüssel "ControlSet001" und "CurrentControlSet".
In beiden Schlüsseln gibt es unter "Control" den Sub-Key "TimeZoneInformation", mit identischen Werten.

Trägt man nun den DWord-Wert "RealTimeIsUniversal" unter "ControlSet001\Control\TimeZoneInformation" ein und setzt ihn auf "1", dann wird der Wert offensichtlich unter "CurrentControlSet" automatisch eingetragen, oder gespiegelt o.s.ä.
 
Ich habe heute an einem Rechner gesehen, daß sich das "Sommerzeitproblem" einfach von selbst gelöst hat. Zunächst war der Rechner noch auf Winterzeit, nach etwa einer Stunde hat er sich ohne weiteres zutun selbst umgestellt (Windows 1803, heute auf neuestes Build upgedatet, Rechner war ca. 2 Monate ausgeschaltet).
 
PeteM92 schrieb:
Ich habe nur Deinen, @Micha45, Post #45 ergänzt, in #45 war das nämlich falsch zitiert.
Zum Vergrößern anklicken....
Ja, das hast du richtig erkannt.
Ich hatte den Beitrag 1:1 aus dem CB-Forum übernommen und mir war erst später aufgefallen, dass der angegebene Schlüssel nicht korrekt ist.
Ich hab's im Beitrag #45 editiert.

Hat sich aber wohl jetzt erledigt mit dem kum. Update KB 4490481.
 
Du musst dich einloggen oder registrieren, um hier zu antworten.
Anzeige
Oben