Schaltsekunde am 31.12.2005 um Mitternacht UTC und GPS

Zitat

Original von Wastl

Nicht unbedingt - auch wenn es im folgenden Beispiel nur eine monetäre Asuwirkung ist/wäre. Nicht wenige Telekom-Unternehmen beziehen ihre Zeitbasis aus dem GPS-Signal. Unter anderem auch für die Abrechnung der Gespräche ... gut, am Silvesterabend fand sicherlich bei keinem Unternehmen ein Tarifwechsel statt. Aber wenn, dann hätte das einiges an Schlamassel bedeutet.

... und es liessen sich sicherlich noch andere Fälle finden, wo das was ausmachen könnte - wenn es denn auffiele

Wastl

Alles anzeigen

Moin Wastl,
wenn ich zeitkritische Anwendungen (Absolute Zeit oder Zeitunterschiede=Dauer) zu berechnen habe, dann
kann ich doch locker diese Schaltsekunden berücksichtigen;
ist ´ne Handvoll Zeilen an Code.
Wolf
...
oder?
.
.
Du hast übrigens eben 2 (zwei) Sterne bekommen.

*Wastl* als "Testobjekt".
Bleibt aber so, falls Du nichts dagegen hast.

Hallo

Zitat

Original von karomue

Ja, und damit sind wir aber bei der DC77-Uhr oder einem Ableger. Und damit habe ich schon zu Zeiten gespielt, als der erste Apple-Computer den PET ablöste - bei mir. PC zur Zeitanzeige mit einem DC77- Empfänger programmiert.

Jo - ich hab auch irgendwo noch so ein DCF77-Modul von Conrad rumliegen und hatte das Zeittelegramm auf dem AMIGA nachprogrammiert...

Ich habe aber gerade auf der Webseite der PTB gesehen, daß das mit dem Farbträger heute nur noch eine untergeordnete Rolle spielt., da zum Beispiel die Digitalisierung des Fernsehens einen Strich durch die Rechnung macht.

Ansonsten ist für die Bestimmung von UTC aus GPS http://www.ptb.de/de/org/4/44/442/gps_vergl.htm relevant. Hier geht es um Nanosekunden.

Zitat

Original von karomue
Und wie genau muss denn die amtl. Zeit wirklich sein?

Als Normalbürger reicht mir das Zeitzeichen im Radio mit seiner Ungenauigkeit im 1ms-Bereich. Als "Freak" sind solche Zustände aber absolut nicht tragbar.

Zitat

Original von karomue
Schon mal einer Bahnhofsuhr zugesehen, die ein (gewolltes??) Vorgehen des Sekundenzeigers durch eine Zwangspause auf der 12 wieder ausgleicht? Ist es relevant, wenn Hauptuhrsteuerungen auf DC77-Basis 1 sek vor- oder nachgehen - warum auch immer???

Das "Vorgehen" und "Warten" des Sekundenzeigers ist wirklich gewollt, da alle Bahnhofsuhren nur einmal pro Minute einen Impuls für den Schrittmotor (des Minutenzeigers) bekommen. Während der Minute läuft der Sekundenzeiger "frei". Und damit er vor Ablauf der Minute garantiert wieder auf der 12 steht, läuft er etwas schneller und wartet dort (etwa eine Sekunde lang) bis der Minutenimpuls kommt. Dann beginnt das Spiel von vorn.

Zitat

Original von karomue
Fest steht, bei dem log kommt die Schaltsek 14 sek zu früh. Ich meine, das ist ein Versehen und kein Exemplarfehler der Maus, die das log geliefert hat, Argumente die m. E. logisch sind, habe ich geliefert.

Soweit ich das sehe, hat man in der von Wastl genannten NG schon die richtigen Fragen zum Log gestellt ("...But this is somewhat puzzling, since the unit dispalys UTC time...??? What GPS unit do you have??"). Wir müssen einfach mal abwarten was da rauskommt. Ich glaube es ist ein Bug des Empfängers. Bei Google findet man auch einige Berichte zu vergangenen Schaltsekunden und wie die GPS-Empfänger damit umgegangen sind.

dwk3: Du hast dich verrechnet. Die Schaltsekunde war um Mitternacht UTC, also nach GPS-Zeit um 00:00:13. Seit 00:00:14 GPS-Zeit werden 14 Sekunden abgezogen. In den UTC-Zeitmarken der NMEA-Datensätze im Log hätte die Schaltsekunde also wirklich erst um Mitternacht erscheinen dürfen.

Guts Nächtle
hevo2

Hallo Wastl,

da gibt es einen Thread über Freude-Liste, irgendwer hat nachgefragt, was die beiden * vor und nach dem Namen in der Liste unten im Startbildschirm sollen. Nun, das ist einfach die Kennung für Freunde.

Zu unserem Problem:

Die Frage war doch, ist der Umschaltzeitpunkt 46. sek. ein Maus(SW)Fehler oder ein Programmierfehler der (Änderungs-) SW?

Es wurde hier vermutet: Mausfehler, während ich Programmierfehler sage:

Mausfehler:
da müsste die Maus doch den Zeitpunkt bestimmen, d.h. sie müsste gewusst haben, dass am 1.1.2006 eine Schaltsek. eingeführt wird. Das ist unwahrscheinlich bis unmöglich.

Programmierfehler:
wir sind uns glaube ich einig darüber, das in der Navigationsnachricht an Zeit GPS und die Differenz zu UTC gesendet wird. Daraus bildet die Maus UTC. Wie genannt, eine einfache Differenzrechnung.

Wann schaltet die Maus nun die Schaltsek.? Logischerweise doch dann, wenn die Differenz geändert wird. Und das hätte zu 23:59:60 (0:00:00) erfolgen sollen, ist aber - versehentlich wie ich behaupte - 14 sek vorher erfolgt. Ich denke, Ihr könnt mit alle folgen. Die Maus macht nur ihre Differenzrechnung einer Differenz, die eben 14 sek zu früh erfolgt.

Alles was sonst gesagt wurde ist rel. irrelevant, selbst wenn ein Tarifwechsel (Tel.) erfolgt wäre, hätten es sicher nur die gefunden, die gerade Sex-Tel. mit Taiwan oder so geführt hätten, wenn der Tarif auch noch um ein mehrfaches gestiegen wäre.

Schön, es geht um die exacte Genauigkeit. Richtig. Zugestanden.

Trotzdem: die Frage war Mausfehler oder Programmierfehler. Und nun erkläre mir mal jemand, wie ein angenommener Mausfehler das hätte bewirken sollen, dass die Schaltsek. 14 sek früher eingespielt wurde.

Vergesst auch nicht, die letzte Schaltsek. ist (programmiertechnisch) Ewigkeiten her. Da ist schon zu vermuten, dass der Programmierer einfach die falsche Zeit oder den falschen Zeitpunkt erwischt hat. Dass er eine (Halb-) Ahnung von der Geschichte hat, zeigt die Differenz von 14 sek. Die war ja immerhin richtig.

Zitat

Original von hevo2
...
dwk3: Du hast dich verrechnet. Die Schaltsekunde war um Mitternacht UTC, also nach GPS-Zeit um 00:00:13. Seit 00:00:14 GPS-Zeit werden 14 Sekunden abgezogen. In den UTC-Zeitmarken der NMEA-Datensätze im Log hätte die Schaltsekunde also wirklich erst um Mitternacht erscheinen dürfen.
...

Moin hevo,
nööh, habe mich wohl undeutlich ausgrdrückt.
- das GPS-Zeitsystem hat die Anweisung bekommen,
beim Jahreswechsel eine Schaltsekunde (+) für UTC einzulegen.
- dann wird vermutlich die gleiche Mimik ablaufen wie bei anderen Atomuhren:
- diese zusätzlich Sekunde wird exakt _vor_ dem neuen GPS-Jahr eingefügt.
- d.h. genau dann erhöht die GPS-SW das Delta zu UTC von 13 auf 14.
Wäre für mich eine plausible Erklärung.
Wolf
...
die "korrekte" dynamische (entspr ZeitDelta) Zeitänderung ist
vermutlich _nie_ geplant/programmiert worden.

Hallo,

wer hätte noch vor wenigen Tagen gedacht, daß uns dieser Thread bzw. diese läppische Sekunde so lange beschäftigen wird....

Und wer sich den Thread in der NG "reingezogen" hat, wird z.B. diesen Link gesenen haben

http://members.cox.net/sylvek/leap/

bzw. die Berichte von anderen Usern gelesen haben, die die Schaltsekunde zur rechten Zeit (also um 23:59:60 UTC) auf ihren Empfängern gesehen haben. Ob die zusätzliche Sekunde nun korrekt im Display dargestellt wurde oder nicht, ist dabei erstmal nebensächlich. Wichtig ist doch nur die Erkenntnis, daß der Receiver mit dem das Log gemacht wurde wohl irgendeine "Macke" haben muß.

Zitat

Original von ex_WolfL
nööh, habe mich wohl undeutlich ausgrdrückt.

Is ja nicht weiter tragisch.

Zitat

Original von ex_WolfL
die "korrekte" dynamische (entspr ZeitDelta) Zeitänderung ist
vermutlich _nie_ geplant/programmiert worden.

Also wenn du damit die Nachkommastellen nach den jetzt 14 (ganzen) Sekunden Zeitdifferenz meinst, dann hat man das damals schon bedacht, denn sie werden im GPS-Signal mit übertragen. (siehe auch den Link zur PTB, wegen des weltweiten Zeitvergleichs)

Beim SiRF-Chip (bei anderen Chips sicher auch) gibt es übrigens einen 1PPS Impuls, der mit 1µs oder weniger Abweichung zu den UTC - Sekundenmarken ausgegeben wird. Ich weiß zwar im Moment noch nicht, wo man diesen Impuls in einem PDA abgreifen und damit irgendwie nutzen könnte, aber das ist ja erstmal nicht so wichtig. (Siehe Sirf-Binary-Protocol "PPS Time" Message ID 52)

bfn hevo2

Zitat

Original von hevo2
...
wer hätte noch vor wenigen Tagen gedacht, daß uns dieser Thread bzw. diese läppische Sekunde so lange beschäftigen wird.... ...

ACK,
wer sowas ähnliches dauernd/länger haben möchte, bitte <hier>.
Wolf

Hallo

Schonmal als kleine Vorankündigung, damit jeder seine Systeme rechtzeitig "hochfahren" kann. Noch ist genug Zeit.

Am

31.12.2008 23:59:59 UTC bzw.
01.01.2009 00:59:59 MEZ

ist es wieder soweit.

Und gleich vorweg: Ein GPS-Empfänger darf im NMEA-Format nicht schon am 31.12.2008 23:59:45 UTC die Schaltsekunde einfügen.

Ich hoffe, wir bekommen diesmal mehr Logfiles zusammen....

bfn hevo2

Zitat

Original von hevo2
Hallo

Schonmal als kleine Vorankündigung, damit jeder seine Systeme rechtzeitig "hochfahren" kann. Noch ist genug Zeit.

Am

31.12.2008 23:59:59 UTC bzw.
01.01.2009 00:59:59 MEZ

ist es wieder soweit.

Und gleich vorweg: Ein GPS-Empfänger darf im NMEA-Format nicht schon am 31.12.2008 23:59:45 UTC die Schaltsekunde einfügen.

Ich hoffe, wir bekommen diesmal mehr Logfiles zusammen....

bfn hevo2

Alles anzeigen

Hi hevo2,

bitte Erinnerung am 15.12. mit "Arbeitsanweisung" für log-Files... :gap

Zitat

Original von hevo2
Und gleich vorweg: Ein GPS-Empfänger darf im NMEA-Format nicht schon am 31.12.2008 23:59:45 UTC die Schaltsekunde einfügen.

Um diese Zeit bin ich sicher nicht fähig, einen log von irgendwas zu machen, auch nicht irgendwo rumzufahren. Da wird gefeiert... [HICKS]

Zitat

Original von Holger Issle
Um diese Zeit bin ich sicher nicht fähig, einen log von irgendwas zu machen, auch nicht irgendwo rumzufahren. Da wird gefeiert... [HICKS]

Dann schalt am besten jetzt schon ein... Mach ich auch so. Gleich nach diesem Posting.

Ich nehme das Log im SiRF-Format auf.

Leider liefert die Firmwareversion 3 nicht die Message 52 (PPS-Timing). Man braucht dazu einen Chip mit Version 2.3.2 oder höher. Wer hat, sollte mit SirfTech auch diese Message einschalten und loggen, denn sie enthält ja das aktuelle Offset zwischen GPS-Zeit und UTC. Um 0 Uhr UTC sollte sich was tun...

Ich wünsche einen guten Rutsch!

bfn hevo2