In der funktion "convertUtcToLocalTimeDate" berechne ich die lokale Zeit
hier in Deutschland.
Das berechnen passt auch alles.
Was mir aber aufgefallen ist, dass wenn ich nebenbei noch meine Uhr am
PC offen habe, dass diese ~3 Sekunden weiter ist.
Und wenn ich mir die Unix zeit auf https://www.unixtimestamp.com/
ansehe, ist diese ~3 sekunden zurück.
Woher kommt dieser doch etwas größere Zeitunterschied?
Welche ist die richtige?
Vielleicht gleicht die NTP Implementierung auf dem µC die Laufzeit des
Signals nicht aus. Dann wäre es allerdings nur eine sehr billigen halbe
Implementierung.
Was ist mit den unregelmäßigen Schaltsekunden, werden die
berücksichtigt? Ist die Liste dieser amtlich angeordneten Schaltsekunden
auf aktuellem Stand?
Stefan ⛄ F. schrieb:> Was ist mit den unregelmäßigen Schaltsekunden, werden die> berücksichtigt?
ich bin mir nicht ganz sicher, ob diese in der Funktion
time(&unixTime);
bzw.
localtime_r(&unixTime, &utcTime);
berücksichtigt werden.
Aber wenn nicht, müssten es doch mehr als 3 Sekunden sein oder?
Was läuft denn eigentlich auf dem PC? Normalerweise zeigt ein ntp-client
doch den Fehler der PC-Uhr relativ zur NTP-Zeit an (z.B. ntpq -pn)?
Und woher stammen time() und localtime_r()? Bei den POSIX-Funktionen ist
ganz klar geregelt, wo Schaltsekunden verarbeitet werden; nämlich
garnicht, weil die in der Unix-Zeit sozusagen eingebaut sind.
Eine amtliche Liste der Schaltsekunden braucht man (nur), wenn man die
Rechneruhr (also die Unix-Zeit) auf TAI statt auf UTC synchronisiert.
Aber wer macht das schon freiwillig ;)
Johannes schrieb:> Aber wenn nicht, müssten es doch mehr als 3 Sekunden sein oder?
Nein. Um UTC aus TAI oder GPS-Zeit abzuleiten, brauchst du eine Liste.
Wenn die ca. 5 Jahre alt ist, fehlen in der Liste die letzten 3
Schaltsekunden. Das passiert gerne mit alten GPS-Empfängern, aber nicht
mit NTP.
Johannes schrieb:
1
>unixTime=tv->tv_sec;/* copy unix seconds to global variable */
da bekommst du doch die NTP-Zeit. Aber dann überschreibst du sie wieder
mit der Rechner-Zeit. Muss ich das verstehen?
1
>time(&unixTime);
2
>localtime_r(&unixTime,&utcTime);
3
>convertUtcToLocalTimeDate(&utcTime);
was macht eigentlich dieses convert? localtime_r() liefert doch schon
unsere lokale Zeit? Was geht da vor?
Bauform B. schrieb:> Johannes schrieb:> unixTime = tv->tv_sec; /* copy unix seconds to global> variable */> da bekommst du doch die NTP-Zeit. Aber dann überschreibst du sie wieder> mit der Rechner-Zeit. Muss ich das verstehen?
Also hier bekomme ich die ntp-zeit und speichere sie mir in einer
globalen vairable (zum einen zur initialisierung und zum anderen zum
update)
Bauform B. schrieb:>> time(&unixTime);>> localtime_r(&unixTime, &utcTime);>> convertUtcToLocalTimeDate(&utcTime);> was macht eigentlich dieses convert? localtime_r() liefert doch schon> unsere lokale Zeit? Was geht da vor?
localtime_r bestimmt ja nur die UTC-Zeit (+-0 Stunden).
mit convertUtcToLocalTimeDate berechne ich die Zeit hier. Hier sind wir
ja eine Stunde weiter.
Also addiere ich quasi eine Stunde und überprüfe dann noch ob es der
selbe Tag ist usw.
Eine sehr schöne Webseite ist
https://uhr.ptb.de/
In der Uhr auf Abweichung clicken, dann sieht man wie genau der Rechner
ist.
Ich weiss aber nicht woher die Zeit kommt, ob von der PTB selbst oder
nicht nur ntp.
Thomas G. schrieb:> Und jetzt?
Bist du nicht der TO und wir wissen immer noch nicht, ob seine PC-Uhr
richtig geht. Annahme, Website und EPS zeigen 3 Sekunden weniger als der
PC, Website zeigt gleiche Zeit wie mein (Unix)-PC -> Zeitanzeige auf dem
PC vom TO ist falsch.
Karl schrieb:> Zeitanzeige auf dem> PC vom TO ist falsch.
Windows scheitert auch mal bei der Nachfrage beim Server.
Irgendwo steht dann aber, wann die letzte Synchronisation erfolgte.
Bauform B. schrieb:> Nein. Um UTC aus TAI oder GPS-Zeit abzuleiten, brauchst du eine Liste.> Wenn die ca. 5 Jahre alt ist, fehlen in der Liste die letzten 3> Schaltsekunden. Das passiert gerne mit alten GPS-Empfängern, aber nicht> mit NTP.
Unsinn.
Das GPS überträgt die aktuelle Anzahl der Schaltsekunden mit den
Almanachdaten. Eine eventuell im Empfänger vorhandene Liste interessiert
allenfalls nach einem Kaltstart bis zum Empfang des betreffenden
Datenblocks.
OK, ich hätte dabei schreiben können, dass das unterwegs auf dem Handy
war. Meine PC-Uhr geht aktuell 0,5 sec vor.
NTP-Zeit kann man auch einfacher haben:
https://werner.rothschopf.net/201802_arduino_esp8266_ntp.htm
Ich habe mich allerdings auch schon mal gefragt, wie das mit den
Schaltsekunden & UNIX-Zeit genau läuft.
Thomas G. schrieb:> Ich habe mich allerdings auch schon mal gefragt, wie das mit den> Schaltsekunden & UNIX-Zeit genau läuft.
Ganz einfach: die UNIX Time kennt Schaltsekunden genausowenig wie
Windows.
Ohne Synchronisation geht die Zeit ab der Schaltsekunde einfach eine
Sekunde vor.
Mit SNTP (simple NTP wie z.B: beim genannten ESP32): bei der nächsten
Synchronisation tritt ein 1s Sprung auf (rückwärts), d.h. es gibt eine
Sekunde dann doppelt.
Mit NTP gibt es mehrere Möglichkeiten.
A) Der NTP Client kennt die Schaltsekunde und hat kein LeapSmear
konfiguriert, dann läuft die Zeit 2s lang nur halb so schnell
B) Der NTP Client kennt die Schaltsekunde und hat LeapSmear aktiviert,
dann wird die Zeit weich angeglichen, d.h. die Sekunde wird über 1 bis
24 Stunden verschmiert.
C) Der NTP Client hat keine Kenntnis der Schaltsekunde, dann wird nach
ein paar Synchronisationsintervallen ein Sprung durchgeführt
durchgeführt, da die Differenz über 128 ms beträgt.
D) ....
Ist das wichtig? Ja, durch falsche Handhabung sind am 1.7.2012 Millionen
von Linux Rechnern Amok gelaufen:
https://www.heise.de/ct/ausgabe/2015-14-Wie-Technik-mit-der-Schaltsekunde-am-30-Juni-umgeht-2681775.html
Michael
