Svenska ElektronikForumet

Efter att ha läst om de olika definitionerna kanske en lösning är att ha två separata tider:
time_t ti_tai; /* okorrigerad tid (Linux, FreeBSD) */
time_t ti_utc; /*korrigerad tid med skottsekunder */

Dock så sägs time() på Linux/FreeBSD vara UTC, men eftersom man struntar i skottsekunder så är det i praktiken TAI. Så en bättre hantering är nog:

time_t ti; /* Systemtid */

Med UTC definierat som utc_of_tai( ti );

Så sätter man upp ett system så går klockan enligt TAI utan skottsekunder. Men blandar man in NTP kommer den att sätta systemklockan time() enligt skottsekunder (UTC). Alltså har man styrsystem som t.ex inbyggda system så kan det vara bra att vara observant på NTP.

Kanske bäst med en specifik klocka där varje sekund korrigeras enligt jordens rotation så att den följer dygnet och året utan hopp och en annan som endast går på antal sekunder sedan epoch (1970-01-01) mha av medelvärdesbildad atomklocka.

Krille Krokodil skrev:De säkraste flygplanen som har funnits i historien är Airbus och Boeings helt mjukvarustyrda fly-by-wire (A330, A340, Being 777)

Så länge ingen kraftig solstorm inträffar

Icecap skrev: "Faran" är inte ett sekund hit eller dit, om alla bara är överens om när klockan är vad, det besvärliga är om man räknar fel. Tar man flygningen med "självplanerande rutter" kan det betyda att en uträkning på när ett flyg befinner sig på en viss plats fram i tiden kan bli helt jävla fel om detta extra sekund t.ex. ger ett negativt värde eller liknande.

Skulle du kunna ge ett sådant räkneexempel?

För i min väld ser det ut som följande:
vid en given tidpunkt har ti_tai och ti_utc har samma värde. Detta eftersom båda utgår från 1jan 1970. men skulle man omvandla räknarens värde till ett datum skulle man få olika svar.

Om man ska beräkna flygplanens kommande position mha historiska possitioner ser jag det som att man i nuläget alltid är vid tiden T[0]
tidigare possitioner är T[-1] och bakåt.
vart man kommer befinna sig i framtiden är T[1] och framåt.

När beräkningen är färdig kan man titta i vektorn T[ positiva tal] för att se vart planet kommer befinna sig i framtiden.
Tiden för planets possition blir då. tiden nu + index omvandlat till sekunder.
Detta tal kan antingen pressenteras som ett specifikt datum eller som att något kommer/kommer inte inträffa om index sekunder.

exemplet ovan illustrerar ett väldigt basic exempel som finns i stort sätt varje skolbok kring reglerteknik eller självlärande system mm.
Det jag vill illustrera med exemplet är att jag inte någonstans kan se att skottsekunden har betydelse.
Går det över huvudtaget att göra dessa beräkningar på formatet yyyy mm dd hh mm ss ??

Anledningen att jag frågar är att jag skulle vilja förstå hur du tänker (eller någon annan) eftersom det verkar så självklart en extra sekunden är ett problem. Själv har jag väldigt svårt att se problemet.
Än så länge är alla överens om att tid är ett jidder. Men jag har jag inte sett något exempel på att det faktiskt kan vara ett problem i verkligheten. Det är mest gissningar och antaganden.

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.

Vilka andra lärdomar fick du?

blueint: Ja du, det var en väl avgränsad fråga det.

Ursäkta men jag bara vill kolla så inte är något fel med min dator .
Är julhelgen en programmerings fri helg ??? Inte ett enda inlägg sedan den 23/12 i Mikroprocessorer.
Gott Nytt År på er

@dangraf, Andra system kan t.ex ange tidsvärden utan att ange om de är med skottsekunder eller utan. Beräknar man med linjär tid kan det bli fel när man åter skall använda den beräkningen i en omgivning som använder annan definition. Det finns också risk att vissa system innehåller en tidpunkt som andra system ser som icke-existerande.

Okorrigerad (ti_tai) tid är nog det som ger minst bekymer. För unixsystem så verkar det också vara den principen som används. Källor till skottsekund är då NTP, DCF77, TDF osv.

GPS-systemet är nog det som hanterar detta mest rationellt. Man skickar ut TAI-19 tiden samt antal aktuella skottsekunder som ett separat värde så att det är helt upp till mottagaren hur det skall hanteras.

Ett känt exempel på vad som händer när klockor börjar skena iväg är patriot systemet. Där 1/3 sekund i differens gjorde att missilen missade med 600 meter.