Nya Karolinskas datasystem slogs ut av skottsekud

[sodjan]

Att den visar 23:59:59 -> 23:59:60 -> 00:00:00 istället för
23:59:59 -> 00:00:00 -> 00:00:01 kan vara det...

[Icecap]

Då skottsekunder blir mer vanliga med tiden känns det som att det är en dålig grundlösning som ligger till grund för detta problem.
Jag kan förstå att man vill tidstämpla händelser och lagra dom sekventiellt, speciellt i ett journalsystem.

Inget tidssystem är ju i grunden trimmat för sekunder över 59, det finns ju de-facto inte, alltså är en tid på xx.xx.60 ett fel som definitivt ska utlösa ett larm men inte krasha hela skiten.

Men låt mig gissa: krav på omhändetagande av skottsekunder är inte inskrivit i kontraktet, alltså dålig upphandling.

[sodjan]

Nej, det är inte dålig upphandling. Det går ju inte att föra in alla
möjliga detaljer av den typen. Däremot så bör så klart systemet
kunna klara av det utan större problem eller krascher.

Kanske var enklare förr då sekundera var hårt kopplat till jordrotationen.
D.v.s. tiden kunde gå marginellt olika fort olika år, men den gick i alla fall
monotont alltid "framåt" utan paus eller att backa...

[Nerre]

Det finns väl i princip inga system idag som räknar tiden i timmar:minuter:sekunder? Alla system har väl en räknare (sen om den räknar hela sekunder eller nån annan form av "tick" varierar kanske) och sen har man funktioner som omvandlar detta till "human readable"?

Problemet är väl om man lagt in i systemet att att sekunderna bara kan vara mellan 00 och 59, då kan det såklart bli fel om de plötsligt blir 60. Men om det handlar om standardbibliotek som man använder så borde det ju vara inlagt stöd för att hantera det korrekt. Vid årsskiftet 1999-2000 så var det ju massor med system som skulle säkras mot milleniebuggen, varför tog man då inte och gjorde en rejäl översyn och eliminerade alla buggar kring "ovanliga" klockslag?

[sodjan]

Du får skilja på "räkna" och "presentera". Här beskrivs problemet och alternativa
lösningar för Red Hat: https://access.redhat.com/articles/15145 (bara som exempel).

Sen så är ju din logik lite tokig.

> ...och sen har man funktioner som omvandlar detta till "human readable"?

Så du menar att systemklockan ska räkna på och funktionen som omvandlar
till presentationsformatet ska ta hänsyn till skottsekunden? Hur länge då?

Systemklockan måste så klart ta hänsyn till skottsekunden och justera
sig en sekund. Stå still en sekund, backa en sekund eller sakta ner över
en lite längre tid (för att bli monoton).

[rvl]

Lättast är väl att stänga ner banksystemen då, de klarar sig säkert utan den sekunden. Andra kritiska system kan ha större behov av att vara tillgängliga 24/7.
Edit: var svar på ett inlägg som ser ut att ha försvunnit???

[svanted]

skottsekund
kan man skjuta med den?

[sodjan]

Lika mycket som ett skottår antar jag.

[Nerre]

Så du menar att systemklockan ska räkna på och funktionen som omvandlar
till presentationsformatet ska ta hänsyn till skottsekunden? Hur länge då?

Precis. Systemklockan räknar "tick" sen en viss referenstidpunkt, och systembiblioteken får sen ha funktioner för att korrekt omvandla detta till "tid".

Problemet är väl om man har icke förutsebara förändringar av tidräkningen, dessa måste då på något sätt införlivas i algoritmerna för att räkna om tiden. Men detta krävs ju för alla system, det finns ju inget system som automatiskt kan hantera detta utan att man talar om för det att "vid den här tidpunkten förändras klockan".

[Gizmo]

Ett system jag jobbar i dagligen fukkade upp sig fullständigt vid skottsekunden.
Orsaken är en bug i Suse som egentligen är patchad för två år sedan, men när man har 24/7 drift så är tillfällena för att uppgradera patchen få, och dilemmat den här gången var att programvaran som körs på samma burkar också måste uppgraderas dvs ett ännu större jobb.

Å andra sidan så löstes det hela med en omstart. Men irriterande.

[Mr Andersson]

Precis. Systemklockan räknar "tick" sen en viss referenstidpunkt, och systembiblioteken får sen ha funktioner för att korrekt omvandla detta till "tid".

Det är väl så nästan alla OS redan gör? Och det innebär att man måste ställa om antingen systemklockan eller referensen.
Tänk som exempel att systemklockan räknar antal sekunder sedan 1900-01-01 00:00:00. Sekunden före skottsekunden är x. Sekunden efter är y. Om man inte ställer om klockan kommer den att säga att y är lika med x+2 när den riktiga tiden istället är y=x+1. Det vill säga, ställer man inte om systemklockan ändras referenstiden till 1899-12-31 23:59:59.

[rvl]

Om systemklockan antas gå i en tidsskala som INTE innehåller skottsekunder, så ändras inte heller referenstiden. I sodjans länk nämndes t.ex TAI och TAI-10, båda utan skottsekunder.

Man vet om kommande skottsekunder i god tid, det har redan officiellt meddelats att det inte blir skottsekund i slutet av juni. Antagligen blir nästa tidigast i juni 2018, men det är bara min gissning. Officiellt meddelas det ett knappt halvår på förhand.

[sodjan]

> Precis. Systemklockan räknar "tick" sen en viss referenstidpunkt.

Precis. Och om det tillkommer en skottsekund så läggas den till systemklockan.

> och systembiblioteken får sen ha funktioner för att korrekt omvandla detta till "tid".

Precis. Men där är det svårt (jag skulle säga, går det inte) att hantera skottsekunder.
Hur skulle det gå till? Ska funktionen hålla reda på hur många skottsekunder det har
varit sedan 1900? Hur många är det? Det är 27 skottsekunder sedan 1972. D.v.s att
systemklockan skulle gå 27 sekunder efter (om 1972 var referens). Blir jäkligt rörigt...

Och systemet måste startas med rätt antal ackumulerade skottsekunder i systemklockan.

Nej, bättre att systemklockan alltid "går rätt" och konverteringar till presentationsformat
sedan fungerar som vanligt.

EDIT: Skottdagar är enklare att hantera, det är mer regelstyrt och man vet i princip
vad som gäller hundratals år fram i tiden. Skottsekunderna går inte att planera i förväg.

[SM6XUN]

Har viktiga system på jobbet så vi bemannade och fick se klockorna visa :59 två gånger,
allt gick bra förutom ett system som visade :60 och fick startas om då ingen programvara i världen förväntar sig en klocka som går till :60

[TomasL]

Såklart. Men ett delvis svar är ju Windows-miljö - och då är det väll bara att ta något vanligt strul från högen skulle jag tro.

Patch som inte fungera? RPC-protokoll som inte ville ta sig genom en brandvägg efter en uppdatering? Kluster som spåra ur? Fick Virus för någon koppla fel i stativet?

Har naturligtvis inte något att göra med vilken miljö programmen körs i, hade samma program skrivits för och körts under Linux miljö eller annan ix miljö, så hade resultatet blivit exakt detsamma.