[Frage] Datum um einen Tag falsch

[RSchnauzer]

Hallo,

ich habe einen eigentümlichen Effekt. Meine FB 7390 zeigt das falsche Datum an (bei Telefon Anrufe, bei System Ereignisse).
In der NTP Einstellung habe ich 0.europe.pool.ntp.org; ntp1.t-online.de stehen.
Jetzt habe auf 0.de.pool.ntp.org; ntp1.t-online.de geändert, aber ich finde keine Stelle an der das aktuelle Datum/Zeit angezeigt wird.
Wenn ich in meinem Win7 Laptop die fritz.box als Zeitserver definiere bekomme ich das richtige Datum angezeigt.
In den Ereignissen kann man das ganze glaube ich nicht kontrollieren, da die bei der Anzeige sortiert werden?
Ich hab mich jetzt selber angerufen, der Anruf von 13.07.16 17:40 wird mit dem 14.07.16 15.20 protokolliert.
Wie kann man die FB dazu bringen die Zeit neu zu synchronisieren? Die box läuft seit über 70 Tagen ununterbrochen.
Booten hilft bestimmt, dann ist aber auch die Chance weg den Fehler zu verstehen.

Kann jemand diese Effekte erklären?

 

[PeterPawn]

Falsche Zeitzone eingestellt?

Geht zwar über das GUI nur bei der internationalen ... aber über die Export-Datei kriegt man das ja auch anders hin.

Zumindest würde das erklären, warum der NTP-Server die korrekte Zeit ausliefert, denn das ist dann alles UTC-basiert.

Wobei das mit UTC+22 schon witzig ist (und als verschobene Zeitzone auch nicht funktioniert, denn die geht von +12 bis -12) ... daher sehe ich hier eher einen Rechenfehler irgendwo in einer Routine, der in Kombination mit der derzeit aktuellen Sommerzeit (UTC+2) und dem Schalttag vom 29.02.2016 in diesem Jahr zu einem falschen Ergebnis führt - wobei die zusätzlich fehlenden 20 Minuten das erst richtig komisch wirken lassen, wenn das nicht nur ein Tippfehler ist, denn das wäre ja eine Differenz von 21:40 h.

Vielleicht aber auch bloß eine Anomalie in der Raumzeit und Deine Frage stammt eigentlich vom morgigen Tag aus unserer Perspektive? Dann stünde aber meine Antwort auch schon hier, bevor Du die Frage geschrieben hast ... das kann es also auch nicht sein.

PS: Vielleicht sollte man noch erwähnen, daß solche Systeme wie die FRITZ!Box die Uhrzeit als Differenz zu einem definierten Startzeitpunkt (bei Linux i.d.R. der 01.01.1970 01:00 Uhr) speichern und damit den aktuellen Wert so einer Zeitangaben in fast allen Fällen auf der Basis dieser Differenz (in Sekunden gespeichert) ermitteln. Erst dachte ich an einen Typfehler bei einer Berechnung (weil auch ich mich verrechnet hatte), aber die Differenz von ~78000 Sekunden paßt dann doch nicht zu dieser Theorie.

 

[koyaanisqatsi]

Moins


Ohne Neustart oder einen Reboot...

1. Trag mal den hier noch dazu ein: times.tubit.tu-berlin.de
2. Nach Übernehmen die Supportdaten erstellen lassen
3. Die Datei mit einem Texteditor öffnen und suchen nach: Chrony status:

Chrony status:
200 OK
210 Number of sources = 5
MS Name/IP address           Stratum Poll LastRx Last sample
============================================================================
^+ 130.149.7.7                   2    6     38   +175us[ +389us] +/-   39ms
^+ 2001:638:809:7::7             2    6     37   +338us[ +552us] +/-   29ms
^+ 193.219.28.2                  2    6     37   +380us[ +594us] +/-   49ms
^+ 213.235.200.199               2    6     37  -3760us[-3546us] +/-   51ms
^* 192.86.14.67                  2    6     37  +5058ns[ +219us] +/-   21ms
210 Number of sources = 5
Name/IP Address            NP  NR  Span  Frequency  Freq Skew  Offset  Std Dev
==============================================================================
130.149.7.7                 4   3     6      3.569   4734.664   -102us   585us
2001:638:809:7::7           4   4     6     89.286   1707.268  +3747us   193us
193.219.28.2                4   3     6    -37.973   1456.338  -2051us   137us
213.235.200.199             4   4     6     34.493    813.457  -3148us    52us
192.86.14.67                4   3     6    105.027    212.771  +3914us  8446ns
Reference ID    : 192.86.14.67 (192.86.14.67)
Stratum         : 3
Ref time (UTC)  : Wed Jul 13 15:07:46 2016
System time     : 0.000000292 seconds fast of NTP time
Frequency       : 28.497 ppm slow
Residual freq   : 105.027 ppm
Skew            : 0.100 ppm
Root delay      : 0.030631 seconds
Root dispersion : 0.009857 seconds

EDIT: Auch mal danach suchen: TZ=

TZ=CET-1CEST-2,M3.5.0/02:00:00,M10.5.0/03:00:00

 

[RSchnauzer]

...
1. Trag mal den hier noch dazu ein: times.tubit.tu-berlin.de
2. Nach Übernehmen die Supportdaten erstellen lassen
...

Danke.
Ich hab erst mal die Supportdaten mit "0.de.pool.ntp.org; ntp1.t-online.de" erstellt, dann mit "times.tubit.tu-berlin.de; 0.de.pool.ntp.org; ntp1.t-online.de"
Es scheint sich nichts geändert zu haben, selbst der Dateinamen der Supportdatei ist mit dem falschen Datum.

Chrony status:  
200 OK
210 Number of sources = 4
MS Name/IP address         Stratum Poll Reach LastRx Last sample
===============================================================================
^* 194.25.134.196                2  10   377   363  +2849us[+3251us] +/-   40ms
^- 176.9.40.142                  2  10   377   17m  -1026us[ -637us] +/-   63ms
^- 87.118.124.35                 2  10   377   809  -2169us[-1776us] +/-   51ms
^- 5.9.39.18                     2  10   377   405   -525us[ -123us] +/-   46ms
210 Number of sources = 4
Name/IP Address            NP  NR  Span  Frequency  Freq Skew  Offset  Std Dev
==============================================================================
194.25.134.196             20  12  357m     +0.005      0.254  +1964ns  1728us
176.9.40.142               25  12   90m     +0.064      0.096  -1002us   178us
87.118.124.35              21  15   83m     +0.115      0.105  -1883us   141us
5.9.39.18                  25  16  101m     +0.112      0.049   -548us   132us
Reference ID    : 194.25.134.196 (194.25.134.196)
Stratum         : 3
Ref time (UTC)  : Wed Jul 13 15:51:07 2016
System time     : 80719.851562500 seconds fast of NTP time
Last offset     : +0.000402482 seconds
RMS offset      : 1097.239868164 seconds
Frequency       : 22.683 ppm fast
Residual freq   : +0.005 ppm
Skew            : 0.271 ppm
Root delay      : 0.015850 seconds
Root dispersion : 0.026020 seconds
Update interval : 1127.6 seconds
Leap status     : Normal
Hostname                   Client    Peer CmdAuth CmdNorm  CmdBad  LstN  LstC
=========================  ======  ======  ======  ======  ======  ====  ====
192.168.178.31               5852       0       0       0       0   324   46y
127.0.0.1                       0       0     160     144       0   46y     0
2002:54b3:d2f0:0:d101:d253:2222:6a9a       3       0       0       0       0   84m   46y

TZ=CET-1CEST-2,M3.5.0/02:00:00,M10.5.0/03:00:00

dann nach Änderung:

Chrony status:
200 OK
210 Number of sources = 5
MS Name/IP address         Stratum Poll Reach LastRx Last sample
===============================================================================
^* 194.25.134.196                2  10   377   826  +2849us[+3251us] +/-   40ms
^- 130.149.7.7                   2   6    17    64    -91us[  -91us] +/-   22ms
^- 176.9.104.147                 2   6    17    64   -320us[ -320us] +/-   45ms
^- 144.76.14.132                 2   6    17    63   -276us[ -276us] +/-   48ms
^- 46.165.194.70                 2   6    17    63  -2308us[-2308us] +/-   24ms
210 Number of sources = 5
Name/IP Address            NP  NR  Span  Frequency  Freq Skew  Offset  Std Dev
==============================================================================
194.25.134.196             20  12  357m     +0.005      0.254  +4466ns  1728us
130.149.7.7                 4   3     7    +55.319   1397.858  +3486us   182us
176.9.104.147               4   3     7    +34.774    680.190  +1933us    86us
144.76.14.132               4   4     7    +51.122   1055.745  +3115us   114us
46.165.194.70               4   4     7     -6.787    250.525  -2723us    30us
Reference ID    : 194.25.134.196 (194.25.134.196)
Stratum         : 3
Ref time (UTC)  : Wed Jul 13 15:51:07 2016
System time     : 80681.265625000 seconds fast of NTP time
Last offset     : +0.000402482 seconds
RMS offset      : 1097.239868164 seconds
Frequency       : 22.683 ppm fast
Residual freq   : +0.005 ppm
Skew            : 0.271 ppm
Root delay      : 0.015850 seconds
Root dispersion : 0.026611 seconds
Update interval : 1127.6 seconds
Leap status     : Normal
Hostname                   Client    Peer CmdAuth CmdNorm  CmdBad  LstN  LstC
=========================  ======  ======  ======  ======  ======  ====  ====
192.168.178.31               5852       0       0       0       0   787   46y
127.0.0.1                       0       0     181     146       0   46y     0
2002:54b3:d2f0:0:d101:d253:2222:6a9a       3       0       0       0       0   92m   46y

TZ=CET-1CEST-2,M3.5.0/02:00:00,M10.5.0/03:00:00

Es hat sich nichts geändert, die Differenz bleibt gleich.
Es scheint weiter die 194.25.134.196 von der Telekom genutzt zu werden.
Ich werd nochmal ohne die Telekom versuchen.

Chrony status:
200 OK
210 Number of sources = 4
MS Name/IP address         Stratum Poll Reach LastRx Last sample
===============================================================================
^* 130.149.7.7                   2   8   377   255   +516us[ +510us] +/-   25ms
^- 193.141.27.1                  2   6    17    58   -798us[ -798us] +/-   38ms
^- 46.163.88.228                 2   6    17    58   +415us[ +415us] +/-   49ms
^- 46.182.19.75                  3   6    17    58   +812us[ +812us] +/-   91ms
210 Number of sources = 4
Name/IP Address            NP  NR  Span  Frequency  Freq Skew  Offset  Std Dev
==============================================================================
130.149.7.7                17   8   20m     -0.013      0.322   +426us   129us
193.141.27.1                4   3     7    -21.312    516.520  -2116us    60us
46.163.88.228               4   3     7     +7.554   1498.355   +870us   249us
46.182.19.75                4   3     7    -40.524   1982.447  -1409us   357us
Reference ID    : 130.149.7.7 (130.149.7.7)
Stratum         : 3
Ref time (UTC)  : Wed Jul 13 16:23:47 2016
System time     : 80565.453125000 seconds fast of NTP time
Last offset     : -0.000006412 seconds
RMS offset      : 647.909179688 seconds
Frequency       : 22.712 ppm fast
Residual freq   : -0.004 ppm
Skew            : 0.160 ppm
Root delay      : 0.031281 seconds
Root dispersion : 0.006569 seconds
Update interval : 140.3 seconds
Leap status     : Normal
Hostname                   Client    Peer CmdAuth CmdNorm  CmdBad  LstN  LstC
=========================  ======  ======  ======  ======  ======  ====  ====
192.168.178.31               5854       0       0       0       0    91   46y
127.0.0.1                       0       0     200     148       0   46y     0
2002:54b3:d2f0:0:d101:d253:2222:6a9a       3       0       0       0       0  115m   46y

TZ=CET-1CEST-2,M3.5.0/02:00:00,M10.5.0/03:00:00

Noch ein Tipp? Sonst muss ich wohl rebooten.

 

[PeterPawn]

Zumindest wird damit ja klar, warum die Differenz zwischen NTP-Server (bzw. den Clients) und der Box selbst besteht (https://chrony.tuxfamily.org/manual.html#tracking-command):

System time : 80719.851562500 seconds fast of NTP time
[...]
System time : 80681.265625000 seconds fast of NTP time
[...]
System time : 80565.453125000 seconds fast of NTP time

Da chrony normalerweise die Zeit langsam ändert (um Sprünge zu vermeiden, die andere Programme irritieren könnten), wird auch der Wechsel des Servers eher nichts bringen ... auch hier verschafft die chrony-Dokumentation Aufschluß, wie das gedacht ist.

Ich tippe auf eine früher notwendige "Beschleunigung" der Uhr und dann wurde das Verlangsamen "vergessen" - jetzt lief das eine Weile zu schnell und nun ist chrony wieder dabei, die Uhrzeit "einzufangen". Die Abweichung wird ja kleiner, wobei das sicherlich eine Weile dauern würde, bevor da wieder halbwegs korrekte Zeiten in der Box selbst ausgegeben werden.

Wobei ich das dann auch nicht verstehe, warum ich ca. 21:40 h als Differenz errechnet habe (auf der Basis der Uhrzeiten in #1), was eigentlich nur ~78.000 Sekunden gewesen wären ... hier stehen aber Werte, die noch einmal um fast 45 Minuten größer sind.

 

[RSchnauzer]

... jetzt lief das eine Weile zu schnell und nun ist chrony wieder dabei, die Uhrzeit "einzufangen". Die Abweichung wird ja kleiner, wobei das sicherlich eine Weile dauern würde, bevor da wieder halbwegs korrekte Zeiten in der Box selbst ausgegeben werden.

...

Danke.
Dann werde ich mal für den Erkenntnisgewinn mit dem reboot warten.
Was zu dem Zustand geführt hat kann ich mir allerdings nicht erklären.
Die einzige Änderung in der letzten Zeit war die Blockierung von zwei lästigen Zeitungswerbern.
Vielleicht gab es ja auch ein Problem mit dem Telekom NTP Server.
Ich warte jetzt ab und melde mich nochmal, wenn es etwas zu ergänzen gibt.

 

[armin56]

Eventuell kann man ja mit einem Telefon, das an der Box angeschlossen ist, folgende Sequenz eintippen und dann den Hörer abheben: #83*HHmmTTMMJJJJ*#91**
Wobei HH = Stunde, mm = Minute, TT = Tag, MM = Monat, JJJJ = Jahr ist. So könnte man die Uhrzeit der Box stellen, so dass die Abweichung von der Realen Zeit des Zeitservers minimal wird, erst dann sieht er sich eventuell veranlasst die Uhrzeit zu korrigieren. (So ist es zumindest bei Windows Systemen, da darf die Uhrzeit nicht zu weit abweichen, falls doch, wird sie durch den Zeitdienst nicht gestellt.)

 

[RSchnauzer]

...folgende Sequenz eintippen und dann den Hörer abheben: #83*HHmmTTMMJJJJ*#91**

Danke.
Das hat funktioniert. Die Ereignisse zeigen wieder die richtige Zeit.
Am DECT Telefon ist die Zeit jetzt richtig, das Datum noch falsch angezeigt.

PS: Nach Aus/An DECT Gerät auch da das richtige Datum