Schaltsekunde am 31.12.2016

[Daniel Baumann]

Hallo zusammen,

ich moechte gerne einige Bedenken zur kommenden Schaltsekunde beruhigen
und erlaeutern, was wir an der BFH dagegen unternehmen.


1. Kurze Zusammenfassung der Hintergruende
------------------------------------------

  * ein Tag auf der Erde enspricht grundsaetzlich genau der Dauer einer
    Rotation der Erde um sich selbst.

  * in einer idealen Welt dreht sich die Erde immer genau gleich schnell
    (daraus abgeleitet die International Atomic Time, TAI).

  * in der Realitaet dreht sich die Erde nicht immer genau gleich
    schnell (enspricht der Coordinated Universal Time, UTC).

  * um die Differenz zwischen TAI und UTC moeglichst klein zu halten,
    wird eine Schaltsekunde eingefuegt (momentan geht TAI der UTC 36
    Sekunden vor, nach der Schaltsekunde werden es 37 Sekunden sein)
    welches in feiner Abstimmung mit den Schaltjahren/-minuten passiert.

  * die naechste Schaltsekunde wird am 31.12.2016 zwischen 23:59:59
    und 00:00:00 (UTC) eingeschoben, d.h. die 59. Minute am 31.12. hat
    61 Sekunden, statt 60.

  * wir befinden uns in der UTC+1 Zeitzone, d.h. die Schaltsekunde
    wird bei uns um 00:59:59 Uhr Ortszeit eingeschoben.

  * fuer weitere Informationen, siehe statt vieler:

    - Ankuendigung im Bulletin des International Earth Rotation and
      Reference System Service (IERS):

      ftp://hpiers.obspm.fr/iers/bul/bulc/bulletinc.dat

    - Wikipedia (fuer viele weiterfuehrende Links zum Thema):

      https://en.wikipedia.org/wiki/Leap_second
      https://de.wikipedia.org/wiki/Schaltsekunde


2. Traditionelles Einfuegen der Schaltsekunde
---------------------------------------------

Uhren koennen die Schaltsekunde grundsaetzlich auf zwei verschiedene,
"traditionelle" Methoden eingefuegen:

  * "Minute mit 61. Sekunden"

    2016-12-31  23:59:58
    2016-12-31  23:59:59
    2016-12-31  23:59:60 <-- Schaltsekunde
    2017-01-01  00:00:00
    2017-01-01  00:00:01

  * "Uhr geht rueckwaerts"

    2016-12-31  23:58:00.000
    2016-12-01  23:58:00.500
    2016-12-01  23:59:00.000
    2016-12-01  23:59:00.500
    2016-01-01  00:00:00.0xx <-- Schaltsekunde
    2016-12-31  23:59:00.0xx
    2016-12-31  23:59:00.500
    2016-01-01  00:00:00.000
    2016-01-01  00:00:00.500

Fuer Software koennen (theoretisch) beide Methoden Probleme verursachen
wenn diese nicht korrekt damit umgehen (z.B. hatten frueher speziell
Buchhaltungsprogramme Muehe damit, wenn die Uhr ploetzlich rueckwaerts
geht).

Heute ist das (praktisch) kein Problem mehr weil alle aktuellen
Betriebssysteme und Applikationen schon seit vielen Jahren das korrekte
Verhalten implementieren (ist ja auch nicht die erste Schaltsekunde -
die letzte war Schaltsekunde war am 30.6.2015, seit 2000 gabs bisher
insgesamt 4 Schaltsekunden).


3. Zusammenhang mit der "automatischen" Uhrzeit via NTP
-------------------------------------------------------

Uhren in Computern gehen nach wie vor.

Um immer eine moeglichst genaue Uhrzeit zu haben, koennen Computer diese
via das Network Time Protocol abgleichen, siehe:

https://en.wikipedia.org/wiki/Network_Time_Protocol

Bei Schaltsekunden kuendigt der NTP Server dies 24h vorher den Clients
mit einem speziellen Flag an. So kann das Betriebssystem des Clients die
Schaltsekunde zuverlaessig und autonom einfuegen (in der Annahme dass
alle Systeme mindestens einmal alle 24h eingeschaltet und mit dem
Netzwerk verbunden sind).

Leider wurde das Handling dieses NTP Flags nicht ueberall korrekt
implementiert. Alle aktuellen und gaengigen Betriebssysteme sind nicht
davon betroffen, offenbar aber einige Geraete aus dem Netzwerkbereich
(Cisco).


4. Modernes Einfuegen der Schaltsekunde (Smearing)
--------------------------------------------------

Um das Problem mit sich inkorrekt verhaltenden Geraeten zu vermeiden,
tendiert man als verantwortungsvoller Betrieber von NTP Servern dazu,
Schaltsekunden via Smearing zu propagieren (vergl. u.a. Google, Amazon,
etc.).

Dabei wird die Schaltsekunde nicht wie traditionell "auf einmal"
eingefuegt, sondern in ganz vielen kleinen Schritten gleichmaessig
verteilt ueber die Dauer von 24h ("schmiereffekt").


5. ...und was machen wir an der BFH?
------------------------------------

An der BFH betrieben wir seit Februar 2016 alle NTP Server unter Linux:

  ntp1.bfh.ch  147.87.224.3  (Hardware)
  ntp2.bfh.ch  147.87.244.3  (VMware Bern)
  ntp3.bfh.ch  147.87.96.3   (VMware Biel)

Da wir modern sind und mit der Zeit gehen, machen auch wir "smearing",
d.h. die BFH NTP Server verschicken *kein* vorgaengies NTP Flag zur
Schaltsekunde.

Solange die BFH NTP Server benutzt werden, bedarf es deshalb keinerlei
Massnahmen fuer sich bzgl. NTP inkorrekt verhaltenden Geraeten.

Wir koennen also alle ruhig schlafen und/oder die gewonnene Zeit
waehrend der Schaltsekunde geniessen :)

Gruesse,
Daniel

-- 
Berner Fachhochschule / Bern University of Applied Sciences
IT-Services / Team Infrastructure Services
Daniel Baumann
IT System Engineer Linux
___________________________________________________________
Dammweg 3, CH-3013 Bern
Phone direct +41 31 848 48 22
Phone Servicedesk +41 31 848 48 48
daniel.baumann at bfh.ch
https://servicedesk.bfh.ch
https://www.bfh.ch
https://linux.bfh.ch