|
Diese Diskussion wurde archiviert.
Es können keine neuen Kommentare abgegeben werden.
|
 |
|
|
|
|
|
|
|
Wäre es nicht so ernst und logisch, man könnte es glatt für einen April-Scherz oder einen Schildbürgerstreich halten: da hat es die Technik also geschafft, 2 offizielle Uhrzeiten zu schaffen.
Mal ne Frage: Unix-Time ist seit 1.1.72 in Sekunden, also damit erstmal unabhängig. Einzig die Umrechnung dieser in die "Menschen-Zeit" ist doch dann relevant - und somit total falsch, weil doch alle die normale Sekunden-pro-Tag&Jahr-Methode hernehmen - also gehen alle Unix-Uhren falsch und werden dank NTP hin und her gebogen....
Noch ein Grund mehr, nach Büroschluß die Armbanduhr wegzulegen und einzig die Dirty-Harry-Zeit zu benutzen: nach Ende der Harald-Schmidt-Show kann man ins Bett, wenn man morgens raus muß....
--
$ cd /dos/c/MICROSO~1
$ rm -rf *
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
...einzig die Dirty-Harry-Zeit zu benutzen: nach Ende der Harald-Schmidt-Show kann man ins Bett, wenn man morgens raus muß....
Tschakka, ich bin nicht alleine! :-)
NSG
P.S. Harald Schmidt mag es scheinbar nicht als "Dirty Harry" bezeichnet oder angesprochen zu werden.
--
"...there are two types of friends in this world. Normal friends and the ones you can code with."
|
|
|
|
|
|
|
|
|
|
|
|
|
hat es die Technik also geschafft, 2 offizielle Uhrzeiten zu schaffen.
Sogar drei: Die astronomische Zeit UT1 (ex GMT), die atomare Zeit TAI und die offizielle Zeit UTC, welche aus den beiden anderen berechnet wird.
Warum das ganze? Nun, landläufig wird eine Sekunde als 1/86400 einer Erdumdrehung angesehen. Das Problem dabei: Die Erdumdrehung ist nicht konstant. Sie schwankt leicht mit abnehmender Tendenz. Die Wissenschaft mag aber keine variablen Masse. Daher hat sie eine Sekunde als Anzahl Schwingungen eines bestimmten Isotops festgelegt (weiss grad nicht mehr, welches). TAI folgt dieser Zeitmessung. UTC folgt prinzipiell TAI, behält aber UT1 im Auge. Jedesmal, wenn die Abweichung UTC/UT1 mehr als 0,9 Sekunden beträgt, wird eine Schaltsekunde eingefügt. Die Satelliten haben aber nur ihre eigene Atomzeit. Ergo weicht deren Zeit immer mehr von der offiziellen Erdzeit ab. Und das kann in der Tat ein Problem sein.
PS: Der Vorschlag lautet, UTC gleich TAI zu setzen, nicht gleich UT1. Aber Heise hats auch falsch.
--
If it's GNU/Linux, it's GNU/BSD, too ;-)
|
|
|
|
|
|
|
|
|
|
|
|
|
Und ich hab extra rdate von BSD gepatcht (so,
daß es mit sntpclock und der PTB synchron ist)
und dem NTP-Maintainer den Patch angeboten (der
es nicht einsehen wollte, und als ich DJB in den
Mund genommen hat, nur noch geflamed hat).
IMHO sollten wir das bisherige Schema beibehalten,
denn UTC abschaffen (bzw. gleich TAI setzen) be-
deutet eine weitere Ungenauigkeit in der Bestimmung
der realen lokalen Zeit, während Navigationssysteme
ruhig TAI verwenden können (bei NTP hat man die
Schaltsekundentabelle, die abgezogen wird).
Status im Moment:
- POSIX spezifiziert:
Kernel-Zeit TAI
User-Zeit TAI
- NTP macht:
Kernel-Zeit UTC
User-Zeit UTC
- Olsons libtz/libc mit rdate -nc macht:
Kernel-Zeit TAI
User-Zeit UTC
Letzteres ist richtig, da man nur so die
Zeitdifferenzen bestimmen kann (die
/usr/share/zoneinfo/right/UTC z.B. enthält
die Schaltsekundentabelle, die POSIX nicht).
Wenn man z.B. berechnen will, wie alt ich,
in Sekunden, bin, ist man sowohl nach POSIX
als auch nach NTP 10 Sekunden (ca.) daneben.
Nur DJB und neu OpenBSD rdate mit -c (und
einer Zeitzone aus right/) machen es richtig;
GNU/Linux kann das auch (ich hab sogar bei
MirBSD einen weiteren Fix eingebaut, damit
das auf ner SuSE kompiliert).
--
mirabile, irc.ipv6.eu.freenode.net:6667 {#deutsch,#ccc,#IceWM,#OpenBSD.de,#IPv6,#freenode,...}
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Ja. Berechne mal in Sekunden, wie alt Du bist.
Richtiger Algoritmus:
- ziehe aktuelle Zeit in UTC (dd.mm.yyyy hh:mm:ss)
- rechne diese in TAI im (Sekunden seit epoch)
- ziehe Geburtszeit in UTC (dd.mm.yyyy hh:mm:ss)
- rechne diese auch in TAI um
- berechne die Differenz der beiden Zahlen
--
mirabile, irc.ipv6.eu.freenode.net:6667 {#deutsch,#ccc,#IceWM,#OpenBSD.de,#IPv6,#freenode,...}
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Ummm, nein. Korrekt ist die Differenz der UTC-Zeiten. Begrüdung wie folgt:
- UT1 ist die natürliche Zeit, und ist prinzipiell immer noch die Grundlage aller Zeitberechnungen.
- TAI ist eine küstliche Zeit, die dazu dient, Sekunden mit konstanter Länge zu erhalten. Die Sekunden sind aber im Schnitt etwas zu kurz.
- UTC folgt prinzipiell TAI, wobei der Fehler von TAI mittels Schaltsekunden ausgeglichen wird.
Berechnest du also die Sekundendifferenz mittels TAI, so erhältst du astronomisch gesehen zu viele Sekunden. Die astronomische Zeit ist aber entscheidend, und das Ergebniss somit falsch.
Fazit: TAI wird nur verwendet, wenn Schaltsekunden ein Problem sind. Meines Wissens ist das im Kernel nicht der Fall. Insofern muss ich dem NTP-Maintainer also recht geben (sorry).
PS: DJB in einer solchen Situation zu erwähnen ist auch ziemlich ungünstig. Da könntest du gerade so gut sagen: "Aber Bill Gates macht das genauso!" ;-)
--
If it's GNU/Linux, it's GNU/BSD, too ;-)
|
|
|
|
|
|
|
|
|
|
|
|
|
Hm, übersiehst Du dabei nicht, daß bei
der Konversion eines Datums von UTC in TAI
automatisch ein paar Sekunden abgezogen werden,
sodaß man _gerade_ die astronomische, richtige,
Zeit bekommt?
Rationale: wenn man UTC minus UTC macht, und
dazwischen ein Tag mit Schaltsekunden liegt, ist
nicht jeder Tag gleich lang. wenn man UT2 - UT2
macht, muß man eh' bei jedem Tag die Anzahl
Sekunden in einer Tabelle nachsehen.
Wenn man TAI minus TAI macht, muß man einfach
(Anzahl der Tage * 86400) Sekunden rechnen.
Der Trick dabei ist, daß NTP _sagt_, es macht
UTC, aber das dem Kernel so unterschiebt, als
ob es TAI wäre.
Re DJB hast Du natürlich Recht - das war auch
mein Erlebnis mit dem NTP-maintainer.
--
mirabile, irc.ipv6.eu.freenode.net:6667 {#deutsch,#ccc,#IceWM,#OpenBSD.de,#IPv6,#freenode,...}
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Mmh, ich finde sowieso die hier besser:
<a href="http://www.intuitor.com/hex/hexclock.html">http://www.intuitor.com/hex/hexclock.h tml </a>
Da muß man sich nur noch über die Länge eines
Tages streiten...
--
mirabile, irc.ipv6.eu.freenode.net:6667 {#deutsch,#ccc,#IceWM,#OpenBSD.de,#IPv6,#freenode,...}
|
|
|
|
|
|
|
|
|
|
|
|
|
Slashcode stinkt. Bei /. hätte das Posting
jetzt etwas, und bei deadly.org ganz anders
ausgesehen.
Können die sich nicht mal einigen?
</rant>
--
mirabile, irc.ipv6.eu.freenode.net:6667 {#deutsch,#ccc,#IceWM,#OpenBSD.de,#IPv6,#freenode,...}
|
|
|
|
|
|
|
|
|
|
|
|
|
Hmm, da müsste es also irgendwo eine Tabelle geben
wann jeweils eine Schaltsekunde eingefügt wurde.
Um von "Sekunden nach 1.1.1972" auf aktuelles Datum und Zeit richtig umzurechnen braucht man diese
Tabelle also. Hab ich mir bisher auch noch nie
überlegt, somit rechnet mein Astronomieprogramm wohl auch um ein paar Sekunden falsch.
|
|
|
|
|
|
|
|
|
|
|
|
|
Ergo ticken wir alle falsch - und jetzt wissen wir auch warum.
Was mir noch eingefallen ist bezüglich ntp:
Es gibt ja ntp-Server die mit der Offiziellen Deutschen Zeit arbeiten (Atomuhr Braunschweig). Diese dürfte somit die Schaltsekunden beachten.
Es gibt auch aber ntp-Server mit GPS-Zeit. Gehen die dann anders?
Ich finde, das ist sowieso nur eine Finte der Werbewirtschaft: da man keiner Uhr mehr auf fast 30 Sekunden genau mehr vertrauen kann, muß man jetzt einen Film oder die Nachrichten schon einige Sekunden vorher einschalten - und bekommt so die Werbung davor aufs Auge gedrückt.
--
$ cd /dos/c/MICROSO~1
$ rm -rf *
|
|
|
|
|
|
|
|
|
|
|
|
|
Zwei Links:
http://cr.yp.to/proto/utctai.html
https://mirbsd.bsdadvocacy.org:8890/active/cvsweb.cgi/src/usr.sbin/rdate/
Guck Dir in Letzterem die ntpleaps.[ch] an;
die Routinen zum Extrahieren der Tabelle aus
dem TZfile sind mein Mist, und der Rest ist
nach DJB-Ideen modelliert (und zum Teil Code
von ihm, der public domain ist).
Das Wichtige ist: Deine /etc/localtime (oder $TZ)
und der rdate-Parameter müssen übereinstimmen.
# export TZ=right/Europe/Berlin
# rdate -nc[a]v ptbtime1.ptb.de
gibt Dir TAI im Kernel (POSIX clock) und UTC beim
Aufruf von /usr/bin/date.
# rdate -n ptbtime1.ptb.de; TZ=posix/Europe/Berlin date
gibt zwar auch UTC aus, aber der Kernel läuft
dann falsch. Das ist, wie ntpd und ntpdate arbeiten.
sntpclock wird von rdate -nc emuliert (-n bedeutet
SNTP Protokoll, -c correct leap seconds, -a use
adjtime() [kann unter Linux crashen] und -v verbose)
--
mirabile, irc.ipv6.eu.freenode.net:6667 {#deutsch,#ccc,#IceWM,#OpenBSD.de,#IPv6,#freenode,...}
|
|
|
|
|
|
