Tickande risker

2005-11-22

Det är inte lång tid sedan vi gick från sommartid till normaltid. En förändring som idag nästintill obemärkt passerar våra IT-system. Annat var det för ett decennium sedan, då krävdes stora insatser för att ställa om alla klockor. Nu förstår alla klockor, utom klockan i bilen, när det är dags för skifte mellan sommar- och normaltid. Dessutom med ett millenniumskifte i bagaget står vi stärkta inför alla tänkbara förändringar i tid. Eller gör vi det?

Det är inte många som är medvetna om att vi skall addera en skottsekund (leap second) i år lagom till tolvslaget på nyårsafton. Orsaken till att man lägger till eller drar ifrån skottsekunder är att jorden inte riktigt roterar med ett varv per dygn och detta måste kompenseras med några års mellanrum. Det är The International Earth Rotation Service (IERS) som håller reda på detta och beslutar när skottsekunder skall läggas till eller dras ifrån. Därför skall ni den dagen till ära räkna in tolvslaget så här 23:59:59, 23:59:60, 00:00:00. Senast detta skedde var för sju år sedan, nyårsafton 1998. Det var alltså innan vi gjort alla ändringar inför millenniumskiftet och innan gemene man förstod vikten av att använda NTP för att ha rätt tid, spårbar tid, i datorerna. Hur våra IT-system kommer att hantera denna skottsekund återstår att se. Det finns en risk att man under de sju år som gått sedan sist har förbisett denna händelse i allt från operativsystem till applikationer.

En annan tickande risk är att Microsoft har bestämt sig för att inte åtgärda den hårdkodade begränsningen i W32time som innebär att man inte kan hantera NTP-svar med en precision bättre än -30 (se krönika i CS 2/9). Sveriges Provnings- och Forskningsinstitut (SP) har planer på att uppgradera de tidsservrar som etablerades 2000/2001 vilka är direkt spårbara till den svenska officiella tidsskalan UTC(SP). En uppgradering av de tidsservrar som finns hos SP och Netnod innebär att precisionen förbättras och den kommer sannolikt att hamna på -31 eller -32. Detta får till följd att alla som använder W32time för att synkronisera tiden mot dessa tidsservrar kommer att betrakta svar från dessa som skräp. I början av november har SP gjorts medvetna om detta problem även om de inte direkt har något ansvar för problemet, men de är nu införstådda med följden av en uppgradering. Lösningen för att säkerställa tidssynkronisering i Windows 2003/XP är att envar ersätter W32time med en NTP/SNTP programvara som inte innehåller samma hårdkodade begräsningar som W32time har.

© 2005 Thomas Nilsson, Certezza AB