Sådan ser et skudsekund ud

Nu har jeg ikke haft noget bøvl med det endnu, men jeg har tænkt mig at der skal tilføjes understøttelse for det i Pyro's DateTime class.
I den forbindelse er det min plan at det skal kunne returnere tiden 23:59:60 da det jo må være mest korrekt. For mig at se, bliver det største problem at informere systemet om at der kommer et skudsekund, da der ikke ser ud til at være nogle faste regler for det.

Wed Dec 31 23:59:57 UTC 2008
Wed Dec 31 23:59:58 UTC 2008
Wed Dec 31 23:59:59 UTC 2008
Wed Dec 31 23:59:60 UTC 2008
Thu Jan 1 00:00:00 UTC 2009
Thu Jan 1 00:00:01 UTC 2009
Thu Jan 1 00:00:02 UTC 2009
Thu Jan 1 00:00:03 UTC 2009

Jeg havde i sinde at sætte mit ur (med indbygget GPS) til at lave en track log for at se hvordan GPS systemet håndterede skudsekundet. Desværre glemte jeg det i min iver for at få fyret noget krudt af.... :)

Jeg har en ide om at en tracklog kunne lave et sjovt spring, men det er udelukkende en fornemmelse. PHK, har du nogen ide om hvordan det i praksis ville foregå eller er GPS systemet bygget til at håndtere skudsekunderne?

/Anders

Jeg har en ide om at en tracklog kunne lave et sjovt spring, men det er udelukkende en fornemmelse. PHK, har du nogen ide om hvordan det i praksis ville foregå eller er GPS systemet bygget til at håndtere skudsekunderne?

GPS selv bruger en tidsskala uden skudsekunder. Den faldt sammen med UTC i 1980, men nu er UTC 15 sekunder efter GPS-tiden. En GPS-enhed der leverer UTC-tid må selv sørge for at oversætte fra GPS-tidsskalaen internt. Satellitterne transmitterer vist fra tid til anden information om forskellen mellem GPS og UTC, men jeg tvivler på at alt GPS-hardware kan finde ud af at tage korrekt hensyn til den lige omkring skudsekundet.

På en UNIX maskine med NTP synkronisering, så det således ud

Ja, det er meget pænt, når man kun ser på sekunderne. Jeg har kigget nøjere efter i loggen fra et par halvtravle servere der logger events flere gange i sekundet. Der gik systemtiden "normalt" fremad indtil cirka 2009-09-01 00:00:00.200, hvor den sprang et sekund tilbage til 2008-12-31 23:59:59.200! Det synes jeg er noget sjusk, men det kan man jo ikke se hvis man kun logger et tidspunkt med sekundpræcision ud en gang i sekundet.

De pågældende servere kører Linux 2.4.26 og kører NTP-servere i stratum 2. Jeg mener bestemt at have læst et sted at ntpd er i stand til at fortælle en kerne at der er et skudsekund på vej (hvis altså kernen implementerer et passende API), men at springe på så underligt et tidspunkt tyder ikke på nogen god kerneunderstøttelse...

For mig at se, bliver det største problem at informere systemet om at der kommer et skudsekund, da der ikke ser ud til at være nogle faste regler for det.

Nej, skudsekunder besluttes først et par måneder i forvejen, efter astronomiske observationer af hvor hurtigt jorden drejer rundt (hvilket varierer uforudsigeligt - der er ukendte processer i planetens flydende indre der spiller ind).

Derudover vil du også få det problem at de fleste OS'ers hvad-er-klokken-API'er i løbet af skudsekundet returnerer præcis samme bits som de gjorde sekundet i forvejen. Så selv om du ved der er et skudsekund, er det ikke lige til at vide om man befinder sig i det eller ej, især hvis man er et lillebitte testprogram der lige er startet og forventes at udskrive et tidsstempel med det samme.

Et kig i min log gav mig:

Jan 1 00:59:59 nnnnnnnn kernel: Clock: inserting leap second 23:59:60 UTC

Det er på min lille mail og web server, som ikke har så travlt. Den er baseret på en Centos (en Redhat afstamning).

/Klaus

Jan 1 00:59:59 vserver kernel: Clock: inserting leap second 23:59:60 UTC
Jan 1 01:00:00 vserver /USR/SBIN/CRON[5242]: (root) CMD (if [ -x /usr/bin/vnstat ] && [ ls /var/lib/vnstat/ | wc -l -ge 1 ]; then /usr/bin/vnstat -u; fi)

Jan 1 00:59:59 nnnnnnnn kernel: Clock: inserting leap second 23:59:60 UTC

Hm, det siger syslog sørme også på præcis samme maskiner jeg fortalte om ovenfor:
[code=text]Dec 31 23:59:59 lswb57 kernel: Clock: inserting leap second 23:59:60 UTC
Jan 1 00:04:25 lswb57 ntpd[9906]: kernel time sync enabled 0001[/code]
Kernen siger den indsætter et skudsekund, men applikationer ser det først 0.2 sekunder for sent. Og tilsyneladende går der 4 minutter efter skudsekundet før ntpd er enig med kernen om hvad klokken er!

Hm, gad vide om ikke loglinjen fra kernen faktisk er skrevet EFTER tiden er blevet sat tilbage til 23:59:59.200 ...

Der har ikke rejst sig nogen grund til bekymring endnu
[code=text]
Jan 1 00:59:59 webserv1 kernel: Clock: inserting leap second 23:59:60 UTC
...
Jan 1 01:28:12 webserv1 ntpd[3902]: kernel time sync status change 0001
[/code]

Der er en tidsstandard kaldet International Atomic Time (TAI). Den er uden skudsekunder og er lig UTC plus et helt antal sekunder. Den er nu 34 sekunder foran. Det er den tid som justeres efter atomure rundt i verden (og ikke jordens rotation). Burde det ikke være den primære tidsskala for it-systemer og UTC blot en visning af tiden til brugere? Er der nogle, der kan forklare, hvorfor man vælger at gemme og kommunikere tid med en "ikke-kontinuert" tidsstandard som UTC?

Almindelig mangel på overblik og fremsyn, tror jeg. Det er næppe muligt at finde et bestemt tidspunkt i historien hvor nogen har taget en udtrykkelig beslutning om at tidsstemplerne skal være UTC i stedet for TAI.

På dette område ophørte innovationen vist med at nogen tænkte "denne maskine har brugere i flere forskellige tidszoner. Lad os sætte systemtiden til GMT og så vise tidspunkter i brugerens tid". Kort efter blev det valg indbygget i så megen kode at det ikke siden har været en realistisk mulighed at vælge om. Længe efter var der nogen der hørte om at det vist var mere moderne/korrekt/høfligt (mindre anglocentrisk?) at sige UTC end GMT, og så blev manualsiderne ændret til at bruge "det nye navn".

Man kan tvivle på om der på det tidspunkt var nogen der var bevidst om at man dermed implicit definerede en diskontinuert tidsskala i stedet for den kontinuerte (men ikke SI-rette) GMT.

UTC i sig selv er jo kontinuert nok; den bliver først diskontinuert når man forsøger at identificere den med "antal sekunder siden 0-tidspunktet" på en måde der ikke får al den gamle GMT-baserede kode til at fejle.

Bjarkes argument er ganske korrekt i en ideel verden. Men hvis det havde vundet tilslutning før det var for sent, havde vi slet ikke haft UTC - så havde det nemlig også været tidsnok til at lade den civile zonetid følge med TAI, og så blæse være med at den meridian hvis middelsoltid passer med den borgerlige tid, driver et par hundrede meter østpå om året.

Hov.. Paster lige mit indlæg fra "Skudsekunder er territoriepisseri"-indlægget..

Godt nytår!

Her er lidt erfaringer med nattens skudsekund:

1. Server hjemme i kælderen med ntpd 4.2.4p4 syncet til hobbes.macvaerk.dtu.dk.

Ingen problemer. Præcis kl 1 lokal tid blev der indsat et skudsekund.

2. Servere hos en kunde med ntpd 4.2.4p4 syncet til "intern windows ntp-server". Jeg gætter på at den interne server kører Windows' egen indbyggede ntp-server.

Jeg kunne ikke se at der var nogen som helst ændring i tiden, og den interne windows (s)ntp-server er stadig ca. 1,3 sekunder foran.

3. Servere hos en kunde med ntpd 4.2.4p4 syncet til nogle routere fra TeleDK/British telecom.

Routerne kører så vidt jeg kan se en ældre udgave af ntpd, så der kom ingen varsler om skudsekundet. Det betød så at serverne i løbet af et par timer på må og få satte tiden 1 sekund tilbage. Heldigvis var der ingen brok fra applikationerne.