Diskussion:Schaltsekunde

Jahres-Zuordnung

Gehört die letzte Schaltsekunde nun zum Jahr 1998, da diese ja vor 00:00:00 Uhr des Jahres 1999 eingefügt wurde? In der Tabelle wird die Schaltsekunde zum Jahr 1999 gezählt, im Text aber geschrieben, dass die letzte zum Jahr 1998 gehört.-- fish (nicht signierter Beitrag von 217.81.226.186 (Diskussion) 17:14, 21. Jan. 2005 (CET))

Hai, Fish,

das ist ganz einfach in Deutschland: weil alles nach GMT (UTC) geht, wird ja eh um 01:00:00 eingefügt, damit ist sofort klar, in welchem Jahr das liegt, und zwar bekommt die erste Minute dieser Stunde 61 Sekunden. Ob davon nun die erste Sekunde die Schaltsekunde ist, ob sie in der Mitte der Minute eingebaut wird oder am Ende der ersten Minute wirkt, das kannst Du bitte selber herausfinden und mir mitteilen.-- FotoFux 00:22, 22. Jan. 2005 (CET)

Hai Fish, ich hätte es natürlich besser wissen müssen: die letzte Minute vor 0:00 UTC erhält 61 Sekunden. Im Unix/Linux-Umfeld kann man das im Unfeld von zic (Zeitzonencompiler)/zcat/time()/localtime() etc. gut sehen und auch daran, dass dort "schon ewig" (also mindestens 20 Jahre) definiert ist, dass der Sekundenteil der Zeitdarstellung 0..60 Sekunden haben kann. --FotoFux 16:12, 1. Jan. 2006 (CET)

Schaltsekunde und Unix-Timestamp

Hi, welche Konsequenzen haben die Schaltsekunden auf den gerne Verwendeten Unix-Timestamp (Unixzeit)? Kann es sein, dass der Unix-Timestamp bei Rückrechnung in UTC mittlerweile 22 Sekunden nachhinkt oder voreilt? Oder ist der Unix-Timestamp auch immer an die aktuelle UTC gebunden, und nicht an die von 1970 (sodass keine 22 Sekunden verschiebung auftreten)? (nicht signierter Beitrag von Abdull (Diskussion | Beiträge) 14:27, 7. Apr. 2005 (CEST))

Interessante Frage. Der englische Artikel en:Unix time behandelt das Problem ausführlich, sogar mit Beispielen. Wenn eine Schaltsekunde auftritt, passiert folgendes: Der Zeitstempel vergrößert sich jeden Tag um genau 86400 Einheiten. Wenn jetzt der Tag eine Sekunde länger dauert, wird diese Sekunde auch zunächst gezählt. In der nachfolgenden Sekunde des nächsten Tages springt der Zähler dann aber eine Sekunde zurück. --Echoray 15:18, 7. Apr. 2005 (CEST)

Abschaffung der Schaltsekunde bis 2600

Wäre dies nicht ein Verzicht der UTC bzw ein setzen UTC := TAI bis 2600? Dann könnte man dies zum Passus Abschaffung der Schaltsekunde dazuschreiben, das diese Abschaffung eigendlich überflüssig ist und zu einem Fehlen eines astronomisch(?), sonnen/Sternenhimmel(?) genauen Zeitsystem für die Erde führt.

Gruß rob rob (nicht signierter Beitrag von 134.130.104.75 (Diskussion) 13:18, 9. Nov. 2005 (CET))

Schaltsekunde 1972 +1 s oder +10 s?

Hallo lt Spiegel online Artikel (http://www.spiegel.de/wissenschaft/mensch/0,1518,392429,00.html) war die Schaltsekunde 1972 10 Sekunden lang. Kann dies jemand wikifizieren?--84.135.146.1 21:02, 27. Dez 2005 (CET)

Per Anfang 1972 wurde das System mit den Schaltsekunden eingeführt und die Anfangsdifferenz zwischen TAI und UTC betrug 10 Sekunden. Per Mitte 1972 wurde die erste Schaltsekunde (von 1 Sekunde) eingefügt (Differenz ab dann 11 Sekunden), per Ende 1972 die zweite Schaltsekunde (Differenz ab dann 12 Sekunden). Quelle: IERS, im Web [1], speziell [2]. Spiegel Online bezeichnet die Anfangsdifferenz von 10 Sekunden übrigens auch nicht als Schaltsekunde, sondern als "globale Atempause". Der Spiegel-Artikel irrt: Die nächste Schaltsekunde ist nicht der 22., sondern der 23. "Uhrenstopp" (oder sogar der 24., wenn man die Anfangsdifferenz per 1.1.1972 als "Uhrenstopp" mitzählen möchte) – wobei die Uhren natürlich nicht gestoppt werden, sondern in der betreffenden Minute auf 61 Sekunden hochzählen. Im Wikipedia-Artikel sind diese Sachverhalte korrekt geschildert. -- Stefan506 23:23, 27. Dez 2005 (CET)

Warum es mehr positive als negative Schaltsekunden geben wird

Aus dem Artikel "Astronomische Zeitmessung" (http://www.maa.mhn.de/Scholar/dt_times.html), Abschnitt "Weltzeit (Universal Time UT), Greenwich-Zeit" und dem Aufsatz "The leap second: its history and possible future" (http://www.cl.cam.ac.uk/~mgk25/time/metrologia-leapsecond.pdf) geht hervor, daß wegen der unterschiedlichen Sekundendefinitionen (UT1 und SI) bisher hauptsächlich immer nur positive Schaltsekunden eingefügt wurden und daß auch in Zukunft negative Schaltsekunden nur äußerst selten vorkommen werden.

--R.Denzer 19:00, 3. Jan 2006 (CET)

...weil die Erde sich tendenziell, durch den Mond gebremst, absolut & relativistisch gesehen, langsamer dreht - und eher unwahrscheinlich schneller (was durch entspr. Masseneinflüsse theoretisch ja möglich wäre). Die Frage, die sich leider, ach, nicht so schnell beantworten läßt, ist: bleibt die Erde eher stehen, oder erlischt vorher die Sonne, und ganz spannend: wird das die Menschheit noch erleben und wo? Antwort eines Physikers auf eine derartige Fragestellung: wenn ich gewußt hätte, dass die Sonne nicht schon in 5 Millionen Jahren, sondern erst in 5 Milliarden Jahren aufhört zu scheinen, hätte ich viel ruhiger schlafen können... :-) --FotoFux 23:39, 11. Jan 2006 (CET)

Laengstes Jahr aller Zeiten?

Ist das laengste Jahr "aller Zeiten" nicht das Jahr, in dem der Julianische Kalender eingefuehrt wurde und ein Jahr m.W. um ca. 3 Monate verlaengert wurde? --129.70.14.2 01:10, 26. Nov. 2006 (CET)Quixy

nein. Dein Jahr war genauso lang wie das davor. Nur für die Zeitrechnung war es länger. --DaB. 01:51, 26. Nov. 2006 (CET)

Es geht aber doch hier gerade um die Zeitrechnung?! --Roentgenium111 00:38, 25. Jun. 2011 (CEST)

Rechenfehler: 1 Schaltstunde in 600 Jahren?

Im Hauptarktikel steht "Wenn etwa im Jahr 2600 eine ganze Schalt-Stunde eingefügt würde, könnte auf die häufigen kleinen – in unregelmäßigen Abständen vorzunehmenden – Anpassungen verzichtet werden." Ist das nicht ein Rechenfehler? Wenn nicht nur alle ca. 1,5Jahre, sondern sogar jedes Jahre eine Schaltsekunde hinzugefügt werden würde, wären es 2600 erst 10min, keine Stunde. Oder sollte es "2060" und "Minute" heißen?? --JoeWei 14:46, 29. Apr. 2008 (CEST)

Die Angabe von einer Schaltstunde im Jahre 2600 stammt von Heise online: Wird die Schaltsekunde abgeschaltet?. Ein Nachrechnen wäre aber sinnvoll, da die Zahl so nicht nachvollziehbar ist. --Fomafix 14:54, 29. Apr. 2008 (CEST)

Der Grund ist ganz einfach: Die allmähliche Verlangsamung der Erdrotation führt zu einer quadratisch ansteigenden Differenz zwischen Sonnenzeit und Atomzeit. Schaltsekunden werden demnach in Zukunft also zunehmend häufiger werden müssen. In ca. 5000 Jahren wird es voraussichtlich alle zwei Wochen eine Schaltsekunde geben müssen. 192.54.36.254 06:08, 1. Aug. 2008 (CEST)

Mittlerweile von der Realität überholt, da auf derselben Seite steht: "Die Erde drehte sich im Jahr 2020 schneller als jemals in den letzten 50 Jahren, sogar – nach jahrzehntelanger stetiger „Verspätung“ – erstmals wieder schneller als mit der der Definition der Sekunde zugrunde liegenden Rotationsgeschwindigkeit, und holte dadurch etwa eine Zehntelsekunde auf." --80.108.40.8 00:47, 9. Apr. 2023 (CEST)

Ok.

Anzeige 23:59:60 als Fehlanzeige interpretieren?

Dies ist ohnehin für die meisten Hersteller wünschenswerter, denn die Anzeige 23:59:60 kann aufgrund fehlender Informationen über die Schaltsekunde auch als Fehlanzeige oder Defekt (fehl-) interpretiert werden.

Gibt es dazu eine Quelle, dass dies der Grund dafür ist, dass Anzeige 23:59:60 nicht verwendet wird? Denn das scheint mir ziemlich unwahrscheinlich, dass jemand dazu in der Lage ist, innert dieser einen Sekunde die Funkuhr zurück zum Händler zu bringen, um sich zu beschweren, dass sie defekt sei. Ebenso würde dieser findige Kunde wohl auch bemerken, dass die Uhr verdächtigerweise zwei Sekunden auf 00:00:00 stehen bleibt, was er natürlich ebenso als Defekt fehlinterpretieren würde. Deivo 16:18, 26. Aug. 2008 (CEST)

Meines Wissens empfängt keine handelsübliche Funkuhr ständig das Zeitzeichen der PTB. Kurzes Zitat aus dem Funkuhr Artikel:

Obwohl das Zeitzeichensignal jede Minute gesendet wird, wird es aus Stromspargründen nur ab und zu empfangen und zum Nachstellen der internen Quarzuhr verwendet. Bei Uhren, die mit größeren Batterien (R6 oder R14) betrieben werden, ist ein Empfang jede volle Stunde üblich, bei Armbanduhren mit Miniaturbatterien (Knopfzellen) nur einmal pro Tag, meist zwischen 2:00 und 4:00 Uhr morgens.

Eine Handelsübliche Funkuhr wird also nie eine Schaltsekunde bemerken, sondern wird beim nächsten abgleich eben ihre interne Quarzuhr entsprechend neu stellen. Der Sonderfall, daß der Empfang des Zeitzeichens genau die Schaltsekunde trifft wird wohl nicht auftreten, da zu selten. Für Uhren mit höheren Anforderungen als im Haushalt, mag es Uhren geben die ständig dem Sender lauschen. --Kleiner Jo 21:33, 1. Sep. 2008 (CEST)

Wenn eine Funkuhr einmal pro Stunde für zwei Minuten die Atomuhr abhört, so wird jede 30. Uhr die Schaltsekunde bemerken. Hat Köln mit 950000 Einwohner 100000 Funkuhren, so werden c.a. 3000 Uhren in Köln die Schaltsekunde bemerken: Das DCF-Signal überträgt pro Sekunde ein Bit, die Bits einer Minute geben die Uhrzeit an: Bit 19 des DCF77-Signales kündigt die Schaltsekunde sauber an. --80.133.123.193 09:14, 4. Okt. 2009 (CEST)

Aus diesem Grund ist die Stelle ohnehin missverständlich formuliert, denn die Information 23:59:60 wird nie übermittelt. Ist es ok, wenn ich diese Stelle entsprechend anpasse? -- Martin schulte (Diskussion) 19:08, 10. Jun. 2012 (CEST)

Und was ist mit dem DFC77-Bit 19? 213.211.197.220 16:14, 27. Okt. 2014 (CET)

Seltsame Formulierung

Ich schicke voraus, dass ich keine Ahnung von dem Thema habe. Aber wenn ich lese "Bis in die 1950er Jahre war die Sekunde als 1/86400 eines mittleren Sonnentages definiert. (...) Seit 1967 ist (...) die Sekunde über eine Resonanz des Cäsiumatoms definiert.", dann frage ich mich: Was war dazwischen? "Bis in die 50er Jahre heißt bis 51 oder 52, meinethalben auch bis 55. Und seit 1967 gilt die neue Definition. War dazwischen keine Zeit? Oder nur eine nicht definierte? Oder hat man solange gebraucht, um die Lösung zu finden? Kann das wer besser formulieren? BerlinerSchule 22:47, 24. Mär. 2009 (CET)

Dazwischen galt die Ephemeridensekunde. Du hast recht, das könnte man wenigstens erwähnen, ich bau das mal ein. -- Perrak (Disk) 20:47, 17. Okt. 2014 (CEST)

Bemerkenswert

Liebe Hauptautoren,
Die Unixzeit hat ihren Bezugspunkt (Nullpunkt) am 1.1.1970 00:00:00 UTC und ignoriert die Möglichkeit von Schaltsekunden. Wenn man die historische Liste der Schaltsekunden betrachtet, stellt man fest, dass es keine außerhalb des Zeitrahmens gibt, der durch die Unixzeit abgesteckt wird. Ich frage mich, ob man diesen Hinweis noch unterbringen kann/sollte.
Beste Grüße --Uncopy 14:02, 8. Feb. 2011 (CET)

Hi Uncopy, dazu hat Fotofux schon alles gesagt: mach mal "man date" auf deinem Linux/Unix: Du wirst sehen, die Sekunde kann 61 Werte, und zwar von 0 bis 60 annnehmen, unabhängig, ob Suse, RedHat, BSD-,hp-,DataGeneral (gibt's nicht mehr), Sun (jetzt Oracle) oder andere Derivate. Warum sollte Unix das NICHT berücksichtigen, wenn ein Wert in der Tabelle der möglichen Werte dafür vorgesehen ist...oder haben alle Unix-Nutzer seit Jahrzehnten diesen Fehler in der man-page übersehen?? Alles klar also! --84.176.205.191 20:26, 10. Apr. 2011 (CEST)

Basis der Sekunde

Laut DUT1 basiert die Sekunde auf den Tageslängen von 1900-1904, laut Schaltsekunde um 1820. Beides ohne QuellenDirkBausB 15:50, 1. Jun. 2011 (CEST)

Nächste Schaltsekunde

Die Spekulation über den nächsten Termin einer Schaltsekunde halt ich hier für deplatziert. Zwar ist Mitte des Jahres voraussichtlich eine fällig, aber eine Einfügung am Jahresende würd zur Einhaltung der Toleranz auch noch locker reichen. Momentan kommt noch die politische Frage dazu, ob man ausgerechnet zur eventuellen Abschaffung der Schaltsekunde die nächste ankündigen will. Beides wird ohnehin in den nächsten Wochen offiziell entschieden.

Eine hyperaktuelle Darstellung im Artikel ist auch besonders fragwürdig, solang er über die weitaus wichtigere Frage der Abschaffung der Schaltsekunde gar nichts sagt. Ich werd die Einfügung deshalb revertieren. --92.229.19.72 10:03, 3. Jan. 2012 (CET)

Die "Spekulation" eines Mitarbeiters der PTB in einem WDR-Feature zur Einführung der UTC wurde bereits heute durch die IERS bestätigt. Soviel zu meiner hyperaktuellen Darstellung. --HubPfalz 23:13, 5. Jan. 2012 (CET)

Drum war die Glaskugelaktion besonders nötig. --78.53.229.194 10:54, 6. Jan. 2012 (CET)

Bisher wurde im Artikel darauf hingewiesen, dass es Ende 2017 eine Schaltsekunde geben werde. Nach dem aktuellen Stand der Dinge ist dies, wie sich aus Bulletin C ergibt, nicht so. Daher habe ich die Angaben im Artikel entsprechend angepasst. (nicht signierter Beitrag von SKohl (Diskussion | Beiträge) 15:22, 22. Dez. 2017 (CET))

Sonnenjahr

Im Artikel wird die Notwendigkeit mit der "Erdrotation" und Astronmischen "Notwendigkeiten" (siehe FAZ heute Hauptseite) begründet. Nun frage ich, was hat die MENSCHENZEIT mit der Erdrotation zu tun? Richtig ist doch, das sich die Erde um die Sonne dreht, in wievielen Sekunden und wieviele Meter (m/s) tut sie das? 80.120.174.245 09:42, 18. Jan. 2012 (CET)

Die Erde dreht sich um sich selbst, was man bei uns "Tag" nennt. Da sie sich eher beim kreiseln verlangsamt, braucht sie für eine Drehung etwas länger als früher. Somit ist ein Tag nicht mehr 86400, sondern 86400,002 Sekunden lang. 84.112.85.71 23:25, 30. Jun. 2012 (CEST)

Ein Sonnentag ist länger als eine Umdrehung, und die letzten 12 Jahre war er im Jahresschnitt durchwegs kürzer als 86'400,001 s, nachdem sich die Erdrotation in den letzten Jahrzehnten beschleunigt hat. --85.181.126.6 14:49, 1. Jul. 2012 (CEST)

Computerprobleme, Erweiterung

Ich habe jetzt keinen Nerv dafür, habe aber ein bisschen was zusammengetragen, vielleicht hat jemand Lust:

• Oracle 2009 (&MS) Oracle tripped up by 'leap second' (Probleme)
• The NTP Timescale and Leap Seconds (wie ist es im NTP definiert, welche drei Möglichkeiten gäbe es)
• Google 2011: Time, technology and leaping seconds (Probleme 2005 und Lösung mit gepatchtem NTP-Server mit “leap smear”)
• Opera 2012-03-12 No step back! (Memento vom 3. Juli 2012 im Internet Archive) (früher wurde es im Linux-Kernel anders gehandhabt)
• Opera 2012-06-01 An humble attempt to work around the leap second (Memento vom 3. Juli 2012 im Internet Archive)
• 2012 (Probleme bei Linux-Kernel und Java-basierenden Programmen)
  • Wired ‘Leap Second’ Bug Wreaks Havoc Across Web
  • CNET 'Leap second bug' causes site, software crashes
  • Presse Schaltsekunde verwirrt beliebte Websites
  • heise Schaltsekunde: Linux kann einfrieren
  • orf.at Schaltsekunde brachte Software ins Straucheln Die australische Airline Quantas musste wegen Ausfällen des Flugreservierungssystems einige Flüge verschieben.
• Die GPS-Zeit vom Satelliten hat keine Schaltsekunde, sie ist immer gleichbleibend ?13? Sekunden unterschiedlich zur TAI. (Da müsste dann eigentlich etwas in der Applikation eingebaut sein, da es oft als Zeitreferenz hergenommen wird (zB NTP-Server Stratum Level 1), oder?)

--Franz (Fg68at) 21:02, 2. Jul. 2012 (CEST)

Eine Bugsammlung wär aber wohl übertrieben. Zu den Grundlagen ist http://www.ucolick.org/~sla/leapsecs/ ziemlich erschöpfend. --85.181.126.49 00:27, 3. Jul. 2012 (CEST)

"Eine solche ungleichförmige Zeitskala ist für viele technische und wissenschaftliche Zwecke nicht brauchbar."

Wenn ich mich richtig an meinen Physikunterricht erinnere, wurde die Atomsekunde überhaupt nur eingeführt, weil SI-Einheiten jederzeit exakt reproduzierbar sein müssen, was mit Durchschnittswerten natürlich nicht funktioniert. Aber was sollen das für "viele technische und wissenschaftliche Zwecke" sein? Klingt so, als ob der Autor das selbst nicht gewusst hätte. -- 217.248.222.230 06:51, 3. Jul. 2012 (CEST)

Anmerkungen zu "Sonstiges"

Die Anmerkung in „Zusammenfassung und Quellen:“ der IP 88.130.211.37 zur Änderung vom 6. Juli 2012 um 14:26 entspricht in keiner Weise dem üblichen bei Wikipedia gepflegten (und gewünschten) Ton.

Auszug: "NTP Protokoll nicht verkraften" ... Abgesehen davon dass es falsch ist, eine der dämlichsten Formulierungen die ich je gehört habe. Gehört in die Kategorie "Computer-Führerschein" oder "Series of Tubes“

Die Frage ist nur, was daran so falsch ist?

Wenn eine Schaltsekunde eingefügt wird, wird ein Logeintrag angelegt. Da im Log natürlich auch die Uhrzeit vorhanden sein soll, muss der Loghandler (klogd) die Uhrzeit holen. Der Zugriff auf die Zeit ist aber während des Timer-Interrupts gesperrt, also wartet der Interrupt auf den Loghandler und der Loghandler auf den Interrupt. Dadurch gibt es dann einen schönen Deadlock. [Quelle]

Natürlich ist dafür der „NTP Daemon“ zuständig und die Aussage „weil das NTP-Protokoll die zusätzliche Sekunde nicht verkraften konnte“ diente vordergründig der OMA-Tauglichkeit in Wikipedia. Experten wissen ja dann sehr schnell wo sie weiter nachlesen können.

Es liegt auf der Hand, dass bei Computer-Fehlfunktionen dieser Art in letzter Konsequenz fast immer ein Programmierfehler (oder Konfigurationsfehler) dahintersteckt (was ja auch der Hinweis auf eine Reihe von betroffenen Kernelversionen im geposteten Artikel nahe legt), nur der Programmierfehler alleine hat nicht die bereits bekannten Probleme ausgelöst.

Damit ein Server betroffen war musste auch einiges zusammen passen:

• Es musste eine dafür anfälliger Kernel-Version laufen (siehe Artikel) - allerdings wurde dafür bereits am 15. März 2012 ein [Patch] gepostet!
• Es musste der NTP Daemon laufen. Wer z.B. nur einmal pro Tag die Zeit mit einem Zeitserver synchronisierte (oder auch mehrmals am Tag), war nicht betroffen. Der NTP Daemon läuft normalerweise immer, und gleicht die Drift der internen Uhr mit dem Zeitserver ab um die Systemzeit noch genauer halten zu können.
• Außerdem musste dieser NTP Daemon unzureichend konfiguriert sein. Man kann nämlich eine „leap-seconds.list“ aus dem Internet laden und diese dem NTP Daemon zur Verfügung stellen, dann weiß der genau wann eine Leap Second (Schaltsekunde) kommt und wie er darauf reagieren soll.
• Es blieben aber auch viele Server verschont auf die zwar alle obigen Merkmale zutrafen, aber zum Zeitpunkt der Schaltsekunde eine sehr geringe Auslastung hatten.

Der Programmierfehler hat zwar das Problem ermöglicht, verursacht hat es aber eine Kombination gegebener Umstände und in der Tat hing der NTP-Server. Daher Vorsicht mit solchen Äußerungen und auf den guten Ton achten! -- Sorbas 48 (Diskussion) 09:36, 9. Jul. 2012 (CEST)

Bekanntheit

Auch wenn es bloß um Sekunden geht, wieso wird kaum davon in den Medien berichtet? Finden Menschen so etwas so irrelevant? Ich hab davon noch nie gehört, bevor ich auf diesen Artikel gestoßen bin.--Explosivo (Diskussion) 01:06, 27. Okt. 2013 (CEST)

Davon wird durchaus berichtet, aber eher in wissenschaftlichen Magazinen als in den allgemeinen Nachrichten. Dafür betrifft es das Leben von Otto Normal wirklich zu wenig. --Kreuzschnabel (Diskussion) 08:27, 28. Okt. 2013 (CET)

Ich könnte jetzt nicht mehr belegen, wann genau das war, aber ich habe durchaus in den ganz normalen TV-Nachrichten schon Berichte darüber gesehen. Das Phänomen ist in den Nachrichtenredaktionen also durchaus bekannt, kommt aber wahrscheinlich nur in katastrophenarmen Zeiten auf den Tisch des Sprechers. --Andreas Ley (Diskussion) 10:25, 28. Okt. 2013 (CET)

Wird halt meist dann erwähnt, wenn es aktuell ist. Und am 31. Dezember haben viele Leute anderes im Kopf, und im Sommer eventuell auch ;-) -- Perrak (Disk) 20:47, 17. Okt. 2014 (CEST)

Hat aber was, wenn am 31.12. alle um 23:59:59 auf die (Funk-)Uhr schauen, und das Teil ist so frech und springt auf :60 ...

*bg* --arilou (Diskussion) 16:24, 20. Okt. 2014 (CEST)

Aber dafür müsste man ja zu den Iren oder Engländern reisen, die GMT+0 sind...

Was sind denn bitte

"Zeitzonen UTC±0 "  ? -- itu (Disk) 21:09, 25. Mär. 2015 (CET)

Zeitzonen werden ja auch mit dem Kürzel UTC±x gekennzeichnet, z.B. UTC+1 für die Mitteleuropäische Zeitzone, oder UTC-5 für die amerikanische Ostküstenzeit (Eastern Standard Time). Die Zeitzone UTC±0 ist also die Westeuropäische Zeitzone, und die „Zeitzonen UTC±0 und westlich“ sind alle Zeitzonen der westlichen Hemisphäre: von UTC±0 bis UTC-12, jeweils einschließlich. -- Sch (Diskussion) 20:29, 26. Mär. 2015 (CET)

Hm danke, das könnte man aber wohl noch etwas verständlicher formulieren, denke ich. -- itu (Disk) 15:25, 28. Mär. 2015 (CET)

Dauer der Erdumdrehung

Hallo Cms metrology du hast heute den Satz

"Mit einer Schaltsekunde wird die Tatsache kompensiert, dass eine Erdumdrehung nicht exakt 24 Stunden dauert."

eingefügt. Ich teile dein Anliegen der Allgemeinverständlichkeit. Aber bei dieser Formulierung ist mit dennoch nicht wohl, denn 24 Stunden ist nicht die Dauer einer Erdumdrehung (diese dauert nur 23 Stunden 56 Minuten), sondern die eines mittleren Sonnentags. Diese Abweichung von 4 Minuten hat aber natürlich nichts mit der Schaltsekunde zu tun. --Digamma (Diskussion) 22:20, 13. Jul. 2016 (CEST)

@Cms metrology, Digamma: Ich habe mal gemäß WP:SM versucht, in die Einleitung mehr OMA-Tauglichkeit zu bringen. Bitte das mehr als Vorschlag zu verstehen. Grüße, Troubled @sset  ^{Work  •  Talk  •  Mail}   12:37, 14. Jul. 2016 (CEST)

Schade, daß du den Vorschlag nicht auf der Diskussionsseite gemacht hast. Im Artikel selbst sollte einklich nur „fertiger“ Text stehen, um Editorgien zu vermeiden. Sei’s drum. Ich finde es auch unglücklich, daß das Stichwort jetzt erst so spät kommt. Dann lieber einen nicht-exakten Satz vorweg und den Rest anschließend. Mein Vorschlag:

Eine Schaltsekunde ist eine Maßnahme der Zeitbestimmung, die dazu dient, kleinste Differenzen zwischen der bürgerlichen Zeit und der tatsächlichen Erdbewegung auszugleichen.

Da die Erde minimal langsamer rotiert als bei der Definition der Sekunde zugrundegelegt wurde, dauert ein tatsächlicher mittlerer Sonnentag um Sekundenbruchteile länger als 60·60·24 = 86.400 Sekunden. Sobald die dadurch verursachte Differenz zwischen koordinierter Weltzeit (UTC) und mittlerer Sonnenzeit (UT1) sich an eine ganze Sekunde annähert, wird in UTC eine Schaltsekunde eingefügt, um sie wieder mit UT1 zu synchronisieren. Die Differenz soll immer kleiner als 0,9 s sein.

--Kreuzschnabel 14:22, 14. Jul. 2016 (CEST)

Danke für die Vorschläge. Insbesondere den letzten von Kreuzschnabel finde ich viel zu kompliziert um "allgemeinverständlich" zu sein. Außerdem glaube ich dass die Formulierung nicht richtig ist, denn mit einer Schaltsekunden wird nichts "bestimmt". Den jetzigen Stand im Artikel finde ich gut. Danke.--Cms metrology (Diskussion) 19:46, 15. Jul. 2016 (CEST)

Aktuelle Anzahl

@Gerhardvalentin: Dein Bearbeitungskommentar:

Revert. Für Verbesserungsvorschläge bitte die Artikeldiskussion verwenden.

Seit wann darf man denn Artikel nicht mehr spontan verbessern?

Das Problem ist, dass bei der jetzigen Version die zukünftige Schaltsekunde am 31. Dezember dieses Jahres schon mitaufgeführt wird und mitgezählt wird. Als Gesamtzahl interessiert aber weniger die Zahl der Schaltsekunden (bzw. die Differenz zu TAI) ab dem 1. Januar 2017, sondern die aktuelle.

Ob die Form, in der die IP das in den Artikel eingebracht hat, die angemessene ist, kann natürlich diskutiert werden. --Digamma (Diskussion) 16:51, 30. Sep. 2016 (CEST)

Danke Digamma für die Verdeutlichung des Kontexts. --Gerhardvalentin (Diskussion) 17:00, 30. Sep. 2016 (CEST)

Linux

Ja wie isses denn?: Welche Distributionen bzw. Kernel insertieren denn die Schaltsekunde? -- itu (Disk) 12:40, 2. Jan. 2017 (CET)

Keine. Unix-Zeit ist keine Zeitskala, sondern eine Kodierung der UTC.

Auch sonst ist im Artikel viel Schrott, da Verbesserungen "revertiert" werden, ändert sich daran auch so schnell nichts. --92.75.201.76

Die Red-Hat-Linux-Doku (1) beinhaltet mehrere detaillierte Hinweise und Varianten zum Behandeln der Schaltsekunde, u.a. diese: "2011-12-31 23.59.60 <-- leap second". Hab bei mir unter RHEL 7 genau das aber noch nicht zum Laufen bekommen. --185.109.153.2 07:37, 10. Apr. 2021 (CEST)

TAI64, Summe der Schaltsekunden, UTC und senderlokale Zeitzone in einem Funk-Zeitsignal ?

Hat jemand eine Quelle, ob die Informationen (a) TAI64 (cr.yp.to/libtai/tai64.html), (b) die jeweils gültige Summe der bisherigen Schaltsekunden (uint32 od. uint64), (c) Jahr YYYY als zB uint32 (GMT+0000) (d) MMDDHHMMSS, SS(0...59(60)), als UTC (GMT+0000), (e) ggf. senderlokale Zeitzone als Zusatzinfo, (f) ggf. weitere Steuersignale ; so oder ähnlich in einem Funk-Zeitsignal verfügbar oder geplant sind ? So etwas wär möglicherweise abschließend hilfreich als Basis für eine korrekte Implementierung von Zeitstempeln in Computersystemen. --185.238.219.20 18:13, 27. Nov. 2019 (CET)

Allein die Übertragung der aktuellen Summe der Schaltsekunden über ein Funksignal wäre schon hilfreich, z.B. über DCF77. Evtl. können dort (DCF77) die derzeitigen Wetterinformationen der Fa. MeteoTime auf den Bits 1-14 etwas zusammenrücken, dann könnte man z.B. alle 4h die Summe der Schaltsekunden mit übertragen. Im Wikipedia-GPS-Artikel wird zudem im dortigen Abschnitt "Zeit"[3] zunächst quellenlos angegeben: "Die Satellitennachricht enthält die aktuelle Differenz zwischen GPS-Zeit und UTC. Damit kann im Empfänger die genaue UTC berechnet werden." Das könnte man mal nachprüfen. Nützlich ist evtl. auch das hier [4], der Aufrufe der Seite erfolgt natürlich zunächst über das Internet. --82.113.98.169 22:23, 29. Nov. 2019 (CET)

negative Schaltsekunde

Werte Kolleginnen, Kollegen und Kollegende!

Vermutlich lasst Ihr Euch (im Gegensatz zu mir(-; nicht von den zeitgenössischen Bettelhinweisen der sog. "Wikimedia Foundation" (WMF) von Beiträgen abschrecken, ich mich dagegen schon: ich verweigere inzwischen die Mitarbeit weil "euer" Interface immer ekliger wird! (NB: dieser Beitrag deutet übrigens eine gewisse Verhandlungsbereitschaft an;-) Wie auch immer, zur Sache:

Etwa eine halbe Stunde vor 2020-11-20 15:19:52 UTC+1 habe ich bei Fefe*[1] gelesen, der Twitterlink ist von ihm, die Hervorhebungen von mir:

> "Sogar das Universum hat die Schnauze voll von 2020: Die Schaltsekunde 2020 fällt aus . ..., denn das heißt: Wir brauchen jetzt erstmalig eine negative Schaltsekunde. Dafür gibt es keinen Code [äh Text] ..."[5]

In "irgendeinem" (beliebig auswählbaren?) "Online-Lexikon" findet sich im Artikel zum Thema**[2] mit allen Fundstellen für "negativ":

---

Einschub Nachweise

• [1] eigent. unwichtig, aber bitte WP:LD selbst suchen ...

• [2] Also Perma und letzte Änderung

---

1. "Sollte sich die Eigenrotation der Erde beschleunigen und der mittlere Sonnentag kürzer als 86400 SI-Sekunden werden, können auch negative Schaltsekunden „eingefügt“, d. h. einzelne Sekunden ausgelassen werden. Bislang ..."
2. "Für den Fall, dass die Erdrotation deutlich schneller werden würde, sind auch negative Schaltsekunden vorgesehen. In diesem Fall ..."

HA! Die Erde dreht durch ... und jetzt? Was wird uns verschwiegen? Seit der Epoche (wikipädianisch: Unixzeit) können keine negativen Schaltsekunden verarbeitet werden? Weil es es noch niemand ausprobiert hat? Oder wie?

Nicht nur nach WP:BLG o.s.ä. wurde Twitter abgewählt, aber was dann als Informationsquelle verwenden? Vielleicht finde ich was, bis dahin twittere zwitscher ich was ... --grixlkraxl (Diskussion) 17:40, 20. Nov. 2020 (CET)

PS: und weil dreimal vorschau _nicht_ reicht, etwas fixing des markups --grixlkraxl (Diskussion) 17:47, 20. Nov. 2020 (CET)

PPS: Inzwischen habe ich mich von "Tim Bray auf Twitter" zu einer fanf.dreamwidth.org domain leiten lassen. Und dort steht als "Tony Finch's blog" unter dem Titel "Leap second hiatus" vom 2020-11-13 22:44 bei fanf: ... (lest doch selbst)

Für mich war hiatus neu, bedeutet aber nach meinem! Dictioniary p. 409 und Lautschrift weggelassen: n (pl -ses) gap in a series, making it incomplete. Mein Interesse ist geweckt:

> "Normally I only pay attention to leap seconds every 6 months when the IERS publishes Bulletin C, the leap second yes or no announcement. But this week brings news from ..."

Da ich nicht mehr vorhabe, irgendwas an wikipedia zu ändern, schreibe ich es hier. Vielleicht interessiert's ja irgendwen. Ich habe interessantere lektüre gefunden. --grixlkraxl (Diskussion) 18:18, 20. Nov. 2020 (CET)

• Mit den schon aufgeführten Links (sozusagen "a.a.o";) findet man einen plain text:

NO leap second will be introduced at the end of December 2020.
The difference between Coordinated Universal Time UTC and the
International Atomic Time TAI is :

    from 2017 January 1, 0h UTC, until further notice : UTC-TAI = -37 s

Leap seconds can be introduced in UTC at the end of the months of December
or June ...,

Und dort als Beleg: http://hpiers.obspm.fr/eop-pc/index.php

Wow, hyper text transfer ohne secure! Wer glaubt denn sowas? --grixlkraxl (Diskussion) 20:17, 20. Nov. 2020 (CET)

• Deswegen kann folgenden Informationen vom angegebenen Ort nicht getraut werden:

Last leap second: 31 December 2016 	
TAI - UTC: 37 s
Next leap second: Not scheduled

Aber immerhin wurde hier auf der Diskussionsseite schon vor über einem Jahrzehnt über die "eigentlich" überflüssige Abschaffung der Schaltsekunde diskutiert, mehr positiv oder mehr negativ? --grixlkraxl (Diskussion) 21:05, 20. Nov. 2020 (CET)

Konsistente TAI & Schaltsekundenoffsetimplementierung auf einem PC ?

Hallo PTB,

gibt es bei Euch einen speziell konfigurierten Referenz- oder Demonstrations-PC mit nutzbaren Office-Anwendungen, dessen PC-Betriebssystemzeit intern "nach TAI" läuft - also kontinuierlich und "ohne Zeit-Sprünge", aber dem Nutzer dann "ledeglich für sein Auge" die Lokalzeit inklusive Zeitzonenoffset und inklusive ggf. automatisch oder manuell veränderlichem Schaltsekundenoffset angezeigt wird - und das Ganze auch mit geeigneter Quellenangabe und Beschreibung der dafür notwendigen oder empfohlenen Betriebssystem-, Filesystem- und HW-Struktur ? --2.200.156.215 20:40, 5. Mär. 2021 (CET)

Das ist hier nicht der richtige Ort für die Frage. Wir sind hier nicht die PTB, sondern die Wikipedia. --Digamma (Diskussion) 21:43, 5. Mär. 2021 (CET)

Im Linux-Manual "GNU Coreutils" findet man immerhin bezogen auf die Zeitverarbeitung eine Erwähnung von "Typical systems" und "Atypical systems", wobei letztere die Schaltsekunden in gewissem Umfang handhaben können (letztes Beispiel im dortigen Abschnitt: "21.1.7 Examples of date"):

 # Typical systems ignore leap seconds: 
date --date='2012-06-30 23:59:59 +0000' +%s 
1341100799 
date --date='2012-06-30 23:59:60 +0000' +%s 
date: invalid date '2012-06-30 23:59:60 +0000' 
date --date='2012-07-01 00:00:00 +0000' +%s 
1341100800 

# Atypical systems count leap seconds: 
date --date='2012-06-30 23:59:59 +0000' +%s 
1341100823 
date --date='2012-06-30 23:59:60 +0000' +%s 
1341100824 
date --date='2012-07-01 00:00:00 +0000' +%s 
1341100825

Klar, das geht natürlich nur mit passend hinterlegten Schaltsekunden-Lookup-Tables sauber für die Vergangenheit; und für die jeweilige Zukunft muss der Lookup-Table manuell oder automatisch sinnvoll aktualisiert werden. Wäre nett, wenn jemand eine Quelle hier posten kann, in der man findet, welches "atypical" Unix/Linux-Betriebssystem diese dokumentierte Schaltsekunden-Verarbeitung unterstützt, bzw. wie sich dies testweise ganz oder zumindest teilweise im jeweiligen "atypical" Betriebssystem aktivieren lässt. Zudem wäre eine Quelle sinnvoll, welches Filesystem denn u.a. den (schaltsekundenfreien) Unix-Timestamp und ggf. optionale Schaltsekundeninformationen beim Abspeichern von Dateien im Filesystem mit vorschreibt. --95.208.129.44 10:59, 22. Mär. 2021 (CET)

Änderung von J744 am 27. Juli 2022

@J744: Mir scheint, deine letzte Änderung zu den Problemen bei der Schaltsekunde am 30. Juni 2012 war nicht durchgehend eine Verbesserung,

• vorher: Das Unternehmen Google umging das Problem durch einen Trick, bei dem über den ganzen Tag hinweg kleine Zeitinkremente für die Zeitsteuerung des NTP-Servers aufsummiert wurden, bis der Zeitunterschied egalisiert war.
• nachher: Das Unternehmen Google verlangsamte daher auf eigenen Rechnern die Zeit am 31. Dezember 2016 ab 14 Uhr pro Sekunde um 0,0014 %, bis man am 1. Januar 2017 um 10 Uhr auf dem korrekten Stand war.

Beides mit Verweis auf die Quelle Schaltsekunde am Wochenende legte viele Rechner lahm, wo es heißt: Verschont von dem an den Millenium-Bug erinnernden Szenario blieb Internet-Riese Google, der seine Server mit einem Trick überlistete. Verteilt über den gesamten Samstag wurden dem für den Zeittakt zuständigen NTP-Server jeweils Millisekunden hinzugefügt, bis die volle Sekunde erreicht war. Die Schaltsekunde am Jahreswechsel 2016/2017 hat damit offensichtlich nichts zu tun. Und dann stimmen vielleicht auch die 14 Uhr und 10 Uhr (UTC?) nicht. Dagegen hat die alte Formulierung die Quelle gut wiedergegeben. Ich habe daher hier die alte Version wieder eingestellt.

Nichtsdetsoweniger mag es sinnvoll sein, die verschiedenen Möglichkeiten der Handhabung von Schaltsekunden durch NTP und Betriebssysteme darzustellen, aber wohl besser im Artikel zu NTP. --PaulSch (Diskussion) 16:04, 27. Jul. 2022 (CEST)

Ergänzungsvorschlag

Hi, habe dazu nichts gefunden, sonst hätt ichs selbst ergänzt. Aber vielleicht kann da jemand sein Wissen dann im Artikel teilen?

Es geht darum, aufzuzeigen, weshalb es genau diese beiden Tage im Juni und Dezember sind?

Gerade der Dezember ist doch sehr wunderlich: Das ist doch wirklich der einzige Tag im Jahr, wo die Bevölkerung genau auf diese Uhrzeit schaut (vor dem Neujahr halt)?!

Wäre auch gut, wenn ebenso jemand die Erfahrung teilen könnte, wie das dann beispielweise in der GMT (UK, Irland) gehandhabt wird beim Countdown zum Neujahr: Da ist doch die Überraschnug groß, wenn nach 235959 235960 folgt und nicht 000000. (nicht signierter Beitrag von 77.181.111.47 (Diskussion) 08:40, 24. Dez. 2024 (CET))