Svenska ElektronikForumet

>På nyårsnatten slogs telefoner och patientlarm på Nya Karolinskas ut av skottsekunden.

Att klara skottsekunden och skottdagar borde vara en självklar kontroll på alla proffselit skapade programvara.........

http://www.dn.se/sthlm/skottsekunden-sl ... tientlarm/

Även:

http://www.dn.se/arkiv/stockholm/journa ... avererade/

Skulle vara kul att veta mer om vad som faktiskt hände...

Övertron på datorer och programmerare är monumental.

På jobbet var det folk inkallade just då för att hantera skottsekunden, men så löste sig allt friktionsfritt också

Det finns en ganska stark opinion för att avskaffa skottsekunderna, men personligen skulle jag hellre se att vi lärde oss handskas med dem rätt. "Bulkprogrammerare" kan kanske inte förutsättas få till det rätt, eftersom ofta använder stora komplexa härken till ramverk, som de omöjligen kan ha full koll på.

Men varför i hela friden blanda in UTC, eller lokal tid system där skottsekunder ger kritiska efekter? Varför inte köra typ TAI eller GPS tid från början och konvertera till annan tidsskala, bara där det behövs?

Sommar/vintertid verkar inte ge lika stora problem? Beror det på att de oregelbundenheterna kommer oftare (eller inte alls om man kör UTC) och regelbundet? Att ställa klockan fram och tillbaka pga sommartid, kunde man för min del helt avskaffa, men skottsekunden ser jag gärna att den hålls kvar.

Ursäkta en naiv fråga, men hur kan en skottsekund slå ut ett telefonsystem?

Det är som vanligt.

http://www.dn.se/arkiv/stockholm/journa ... avererade/

...journalsystemet Obstretrix fortfarande nere på alla Stockholms förlossningsavdelningar...

http://www.meridianhi.com/index.php/obstetrix

Obstetrix is built on Microsoft's .NET Framework and SQL Server

Som tekniker och intresserad av driftfrågor vill man ju väldigt gärna
veta vad som faktiskt hände. Att det var "Microsoft's .NET Framework
and SQL Server" säger inte ett smack, enbart det i sig kan inte orsaka
problem och driftstörningar...

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?

Ett vanligt problem är väl tidsbaserade krypteringar osv som inte gillar när det blir samma tid igen

Men med skottsekunder blir det ju inte samma tid igen. 58, 59, 60, 00, 01...

..Och hur många klockor i diverse system presenterar det på det viset ?

Ja du Glenn, jag har ingen aning. I standard C presenteras det så men om underliggande klocka gör det vet jag inte. Vet du?

Med unix timestamp blir det knepigare. Typ tre dåliga lösningar:

• klockan backar
  klockan står still
  sekunden smetas ut under ett antal timmar före och efter

Att klockan visar samma tid i två sekunder kan väl inte vara såååå problematiskt?