Det är intressant att alla verkar hänga sig det extra sekund när det verkliga problem är om någon formel kan ge fel värde.
Ett exempel är svårt att ge, hur ska jag veta hur system tar in detta skottsekund? Det måste nödvändigtvis vara större system som måste ha synkroniserade klockor, t.ex. banksystem som handlar med varandra.
Om t.ex. en överföring sker 2012-12-01 12:34:
60 (60 pga. skottsekund) kan den mycket väl avfärdas som "fel på data" för att det mottagande system gör den vanliga koll "timmar mellan 0 och 23, minuter mellan 0 och 59, sekunder mellan 0 och 59". Detta kan betyda att alla överföringar under det sekund kan gå helt åt pipan och återsändning är ingen lösning då transaktionen ju är stämplat med detta "ogiltiga" tidpunkt.
Och då det sker en våldsam massa transaktioner dygnet om mellan banker kommer detta att generera en mängd "manuellt" arbete och mycket strul.
För mig och min DCF77-klocka har det ingen som helst betydelse, inte heller för mina datorer som synkar med internettid, något sekund hit eller dit är ju intensivt likgiltigt. För de interna enheter jag har som har någon klocka i sig är tiden linjär för dom, det är inget problem alls.
Ett annat exempel:
Om man ska sortera tidsstämplade händelser brukar det att vara enklast att räkna om till antal sekunder sedan ett visst datum. Men blir denna omräkning korrekt när tidstämpeln blir som ovan? Om vi bara utgår ifrån klockan blir värdet för:
* 12:34:59 = 45299
* 12:34:60 = 45300
* 12:35:00 = 45300
Alltså är det med den tidstämpling omöjligt att veta om det har hänt 12:34:60 eller 12:35:00 eller hur? Och jag kan tänka mig att detta kan vara kritisk i vissa sammanhang, jag skulle t.ex. inte gärna se denna otydlighet i ett kärnkraftverk... Det kan även ha signifikant betydelse vid överföringar inom banker eller liknande.
Den sista tiden (12:35:00) är i övrigt fel uträknat när det blir skottsekund inräknat, då förutsatt att man har en absolut "antal sekunder sedan <fast datum & tid>". Om man t.ex. räknar sedan 1970-01-01 00:00:00 ska man egentligen räkna med de skottsekunder som har tillkommit under perioden om värdet ska vara korrekt - men då man oftast mest använder värdet till "skillnaden mellan <datum & tid A> och <datum & tid B>" avsett som t.ex. "3 dager, 14 timmar, 12 minuter och 7 sekunder sedan" är skottsekunden faktisk en nackdel då vi oftast avser "människotid" när det räknas på detta vis.
Så problemet är just skillnaden mellan denna matematisk korrekta tid och "människotid".
Om precis
alla blir överens om att när det blir dags för et skottsekund kommer det att anges datum och tid och då kommer alla tider att stega upp 2 sekunder istället för 1 som brukligt är, då är alla glada och överföringar kan helt enkelt inte ske på fel sätt. Sekunder kan kan inte bli 60, de går istället från 59 till 01, på det vis faller ett sekund bort men om alla gör exakt likadan och förväntar sig detta är det ju enkelt avklarat.
