Svenska ElektronikForumet

27 tror jag.

Edit: Vet jag. https://en.wikipedia.org/wiki/Leap_second

Ah, OK, så är det ju ja... Tidigare så baserades tidmätningen
hårt mot jordrotationen. I och med atomurstiden infördes och tiderna
började glida isär, så infördes skottsekunden 1972. OK...

Men i alla fall. Eftersom man inte vet i förväg (alltså typ 10 år i förväg)
att en skottsekund kommer, så blir det svårt att ha rutiner i koden för att
räkna ut ändringen. Skottår är enklare och de är inga överraskningar.

Bah, sodjan hann före, jag ville bara poängtera att en mjukvara som ska hantera skottsekunder på det sättet måste uppdateras varje gång det blir en skottsekund just pga det.

Jag har ju jobbat med programvaror som inte varit uppdaterade sen 90-talet men fortfarande är i drift, då blir det lite krångligare.

Visst, i praktiken kommer det inte att fungera. Om inte alla kör W10 förståss och tillåter uppdateringar.

I förrgår insåg jag att XP är stendött (lika bra det) när Cygwin inte supportar XP längre.

Jag fattar nog inte det här med "problem att referenstiden hoppar", är det inte exakt det som händer när os:et ställer systemklockan mot någon känd referenstid (NTP t.ex.)??
Detta sker ju lite titt som tätt, och klockan i en vanlig dator kan ju driva rätt bra på några månader, definitivt mer än någon sekund iaf...

/j

sodjan skrev:Men det har ju varit 27 skottsekunder sedan 70-talet.
Hur ska du hålla reda på alla dom med "en enkel IF-sats"?
Och hur många har det varit sedan år 1900?

Läste du slarvigt?

Nerre skrev: Det är algoritment för att räkna om tiden som ska innehålla en enkel IF-sats för varje skottsekund.

Notera slutet på meningen.

johano skrev:Jag fattar nog inte det här med "problem att referenstiden hoppar", är det inte exakt det som händer när os:et ställer systemklockan mot någon känd referenstid (NTP t.ex.)??

Ja, och det kan ställa till problem i system som vill veta hur lång tid det gått mellan två händelser.

Om man struntar i att klockan går lite fel så kan man ju strunta i skottsekunden också.

Här är ett lite annat svar där skottsekunden igår (på slutet).
Det var en kund med ett VMS system som hade gjort en
felrapport angående att år 2000 felaktigt (enligt kunden)
räknades som ett skottår. Detta var 1983. Kunden fick i
alla fall ett heltäckande och tydligt svar från supporten...

http://h41379.www4.hpe.com/openvms/prod ... /leap.html

Dagens höjdpunkt kan undra vad kundens reaktion var?

Nu när tråden ändå är inne på ett stickspår så tar vi en till...

http://www.slac.stanford.edu/~rkj/crazytime.txt

Innehåller en hel del intressant tid och datum historik.

Sista raderna lyder:

"Note that the OpenVMS time display and manipulation routines allow for
only 4 digits in the 'YEAR' field. We expect this to be corrected in a future
release of OpenVMS sometime prior to 31-DEC-9999."

Ger lite perspektiv på "2038 problemet"...

Och tiden börjar gå "baklänges" år 31086