Unix tid

Aktuell Unix-tid 1679180815 () 2023-03-18T23:06:55+00:00

Unix-tiden passerade 1 000 000 000 sekunder 2001-09-09T01:46:40Z. Det firades i Köpenhamn, Danmark på en fest som hölls av den danska UNIX User Group klockan 03:46:40 lokal tid.

Unix-tid är en datum- och tidsrepresentation som ofta används i datoranvändning . Den mäter tiden med antalet sekunder som har förflutit sedan 00:00:00 UTC den 1 januari 1970, början av Unix- epoken , mindre justeringar som gjorts på grund av skottsekunder .

Unix-tid har sitt ursprung som systemtiden för Unix- operativsystem. Det har kommit att användas flitigt i andra datoroperativsystem , filsystem , programmeringsspråk och databaser .

Definition

Två lager av kodning utgör Unix-tid. Det första lagret kodar en tidpunkt som ett skalärt reellt tal som representerar antalet sekunder som har gått sedan 00:00:00 UTC torsdagen den 1 januari 1970. Det andra lagret kodar det numret som en sekvens av bitar eller decimalsiffror .

Unix-tiden skiljer sig från både Coordinated Universal Time (UTC) och International Atomic Time (TAI) i sin hantering av skottsekunder . UTC inkluderar skottsekunder som justerar för diskrepansen mellan exakt tid, mätt av atomklockor , och soltid , relaterad till jordens position i förhållande till solen. International Atomic Time (TAI), där varje dag är exakt 86 400 sekunder lång, ignorerar soltiden och förlorar gradvis synkroniseringen med jordens rotation med en hastighet av ungefär en sekund per år. I Unix-tid innehåller varje dag exakt 86 400 sekunder men skottsekunder räknas med. Varje skottsekund använder tidsstämpeln för en sekund som omedelbart föregår eller följer den.

Kodning av tid som ett tal

Unix-tid är ett enskilt tecken som ökar varje sekund, vilket gör det lättare för datorer att lagra och manipulera än konventionella datumsystem. Tolkprogram kan sedan konvertera det till ett läsbart format.

Unix - epoken är tiden 00:00:00 UTC den 1 januari 1970. Det finns ett problem med denna definition, eftersom UTC inte existerade i sin nuvarande form förrän 1972; denna fråga diskuteras nedan. För korthetens skull använder resten av detta avsnitt ISO 8601 datum- och tidsformat, där Unix-epoken är 1970-01-01T00:00:00Z.

Unix-tidstalet är noll vid Unix-epoken och ökar med exakt 86 400 per dag sedan epoken. Således representeras 2004-09-16T00:00:00Z, 12 677 dagar efter epoken, av Unix-tidstalet 12 677 × 86 400 = 1 095 292 800 . Detta kan även förlängas bakåt från epoken med hjälp av negativa tal; alltså 1957-10-04T00:00:00Z, 4472 dagar före epoken, representeras av Unix-tidstalet −4472 × 86 400 = −386 380 800 . Detta gäller även inom dagar; tidsnumret vid en given tidpunkt på en dag är antalet sekunder som har gått sedan midnatt som började den dagen, adderat till tidsnumret för den midnatten.

Ibland kallas Unix-tiden av misstag som epoktid , eftersom Unix-tiden är baserad på en epok och på grund av ett vanligt missförstånd att Unix-epoken är den enda epoken (ofta kallad " epoken ").

Hoppa sekunder

Ovanstående schema innebär att på en normal UTC-dag, som har en varaktighet på 86 400 sekunder, ändras Unix-tidsnumret på ett kontinuerligt sätt över midnatt. Till exempel, vid slutet av dagen som används i exemplen ovan, framskrider tidsrepresentationerna enligt följande:

Unix-tid över midnatt till 17 september 2004 (ingen skottsekund)
TAI (17 september 2004)	UTC (16 till 17 september 2004)	Unix tid
2004-09-17T00:00:30.75	2004-09-16T23:59:58.75	1 095 379 198 .75
2004-09-17T00:00:31.00	2004-09-16T23:59:59.00	1 095 379 199 , 00
2004-09-17T00:00:31.25	2004-09-16T23:59:59.25	1 095 379 199 .25
2004-09-17T00:00:31.50	2004-09-16T23:59:59.50	1 095 379 199 .50
2004-09-17T00:00:31.75	2004-09-16T23:59:59.75	1 095 379 199 .75
2004-09-17T00:00:32.00	2004-09-17T00:00:00.00	1 095 379 200 , 00
2004-09-17T00:00:32.25	2004-09-17T00:00:00.25	1 095 379 200 .25
2004-09-17T00:00:32.50	2004-09-17T00:00:00.50	1 095 379 200 , 50
2004-09-17T00:00:32.75	2004-09-17T00:00:00.75	1 095 379 200 , 75
2004-09-17T00:00:33.00	2004-09-17T00:00:01.00	1 095 379 201 , 00
2004-09-17T00:00:33.25	2004-09-17T00:00:01.25	1 095 379 201 .25

När en skottsekund inträffar är UTC-dagen inte exakt 86 400 sekunder lång och Unix-tidsnumret (som alltid ökar med exakt 86 400 varje dag) upplever en diskontinuitet . Skottsekunder kan vara positiva eller negativa. Ingen negativ skottsekund har någonsin deklarerats, men om en skulle vara det, skulle Unix-tidstalet vid slutet av en dag med en negativ skottsekund hoppa upp med 1 till början av nästa dag. Under en positiv skottsekund i slutet av en dag, som inträffar ungefär vart och ett halvt år i genomsnitt, ökar Unix-tidstalet kontinuerligt in i nästa dag under skottsekunden och hoppar sedan tillbaka med 1 i slutet av skottsekunden. (återgår till början av nästa dag). Till exempel, detta är vad som hände på strikt överensstämmande POSIX.1-system i slutet av 1998:

Unix-tid över midnatt till 1 januari 1999 (positiv skottsekund)
TAI (1 januari 1999)	UTC (31 december 1998 till 1 januari 1999)	Unix tid
1999-01-01T00:00:29.75	1998-12-31T23:59:58.75	915 148 798 .75
1999-01-01T00:00:30.00	1998-12-31T23:59:59.00	915 148 799 , 00
1999-01-01T00:00:30.25	1998-12-31T23:59:59.25	915 148 799 .25
1999-01-01T00:00:30.50	1998-12-31T23:59:59.50	915 148 799 .50
1999-01-01T00:00:30.75	1998-12-31T23:59:59.75	915 148 799 , 75
1999-01-01T00:00:31.00	1998-12-31T23:59:60.00	915 148 800 , 00
1999-01-01T00:00:31.25	1998-12-31T23:59:60.25	915 148 800 .25
1999-01-01T00:00:31.50	1998-12-31T23:59:60.50	915 148 800 , 50
1999-01-01T00:00:31.75	1998-12-31T23:59:60.75	915 148 800 .75
1999-01-01T00:00:32.00	1999-01-01T00:00:00.00	915 148 800 , 00
1999-01-01T00:00:32.25	1999-01-01T00:00:00.25	915 148 800 .25
1999-01-01T00:00:32.50	1999-01-01T00:00:00.50	915 148 800 , 50
1999-01-01T00:00:32.75	1999-01-01T00:00:00.75	915 148 800 .75
1999-01-01T00:00:33.00	1999-01-01T00:00:01.00	915 148 801 , 00
1999-01-01T00:00:33.25	1999-01-01T00:00:01.25	915 148 801 .25

Unix-tidsnummer upprepas i sekunden omedelbart efter en positiv skottsekund. Unix-tidsnumret 1 483 142 400 är således tvetydigt: det kan hänvisa antingen till början av skottsekunden (2016-12-31 23:59:60) eller slutet av den, en sekund senare (2017-01-01 00 :00:00). I det teoretiska fallet när en negativ skottsekund inträffar orsakas ingen tvetydighet, utan istället finns det ett intervall av Unix-tidsnummer som inte refererar till någon punkt i UTC-tid alls.

En Unix-klocka implementeras ofta med en annan typ av positiv språngsekundhantering associerad med Network Time Protocol ( NTP). Detta ger ett system som inte överensstämmer med POSIX-standarden. Se avsnittet nedan om NTP för detaljer.

När det handlar om perioder som inte omfattar en UTC-skottsekund är skillnaden mellan två Unix-tidsnummer lika med varaktigheten i sekunder av perioden mellan motsvarande tidpunkter. Detta är en vanlig beräkningsteknik. Men där skottsekunder inträffar ger sådana beräkningar fel svar. I applikationer där denna nivå av noggrannhet krävs, är det nödvändigt att konsultera en tabell med skottsekunder när man hanterar Unix-tider, och det är ofta att föredra att använda en annan tidskodning som inte lider av detta problem.

Ett Unix-tidsnummer omvandlas enkelt tillbaka till en UTC-tid genom att ta kvoten och modulen för Unix-tidsnumret, modulo 86 400 . Kvoten är antalet dagar sedan epoken, och modulen är antalet sekunder sedan midnatt UTC den dagen. Om det ges ett Unix-tidsnummer som är tvetydigt på grund av en positiv skottsekund, tolkar denna algoritm det som tiden strax efter midnatt. Det genererar aldrig en tid som är under en skottsekund. Om det ges ett Unix-tidsnummer som är ogiltigt på grund av en negativ skottsekund, genererar det en lika ogiltig UTC-tid. Om dessa förhållanden är betydande är det nödvändigt att konsultera en tabell med skottsekunder för att upptäcka dem.

Icke-synkron Network Time Protocol-baserad variant

Vanligtvis är en Unix-klocka i Mills -stil implementerad med skottsekundershantering som inte är synkron med ändringen av Unix-tidsnumret. Tidstalet minskar initialt där ett språng skulle ha skett, och sedan hoppar det till rätt tid 1 sekund efter språnget. Detta gör implementeringen enklare och beskrivs i Mills papper. Detta är vad som händer över en positiv skottsekund:

Icke-synkron Mills-stil Unix-klocka över midnatt till 1 januari 1999 (positiv skottsekund)
TAI (1 januari 1999)	UTC (31 december 1998 till 1 januari 1999)	stat	Unix klocka
1999-01-01T00:00:29.75	1998-12-31T23:59:58.75	TIME_INS	915 148 798 .75
1999-01-01T00:00:30.00	1998-12-31T23:59:59.00	TIME_INS	915 148 799 , 00
1999-01-01T00:00:30.25	1998-12-31T23:59:59.25	TIME_INS	915 148 799 .25
1999-01-01T00:00:30.50	1998-12-31T23:59:59.50	TIME_INS	915 148 799 .50
1999-01-01T00:00:30.75	1998-12-31T23:59:59.75	TIME_INS	915 148 799 , 75
1999-01-01T00:00:31.00	1998-12-31T23:59:60.00	TIME_INS	915 148 800 , 00
1999-01-01T00:00:31.25	1998-12-31T23:59:60.25	TIME_OOP	915 148 799 .25
1999-01-01T00:00:31.50	1998-12-31T23:59:60.50	TIME_OOP	915 148 799 .50
1999-01-01T00:00:31.75	1998-12-31T23:59:60.75	TIME_OOP	915 148 799 , 75
1999-01-01T00:00:32.00	1999-01-01T00:00:00.00	TIME_OOP	915 148 800 , 00
1999-01-01T00:00:32.25	1999-01-01T00:00:00.25	TID VÄNTA	915 148 800 .25
1999-01-01T00:00:32.50	1999-01-01T00:00:00.50	TID VÄNTA	915 148 800 , 50
1999-01-01T00:00:32.75	1999-01-01T00:00:00.75	TID VÄNTA	915 148 800 .75
1999-01-01T00:00:33.00	1999-01-01T00:00:01.00	TID VÄNTA	915 148 801 , 00
1999-01-01T00:00:33.25	1999-01-01T00:00:01.25	TID VÄNTA	915 148 801 .25

Detta kan avkodas ordentligt genom att vara uppmärksam på den andra språngtillståndsvariabeln, som otvetydigt indikerar om språnget har utförts ännu. Tillståndsvariabeländringen är synkron med språnget.

En liknande situation uppstår med en negativ skottsekund, där sekunden som hoppas över är något för sent. Mycket kort visar systemet ett nominellt omöjligt tidsnummer, men detta kan detekteras av TIME_DEL-tillståndet och korrigeras.

I denna typ av system bryter Unix-tidsnumret mot POSIX runt båda typerna av skottsekund. Att samla in den steg andra tillståndsvariabeln tillsammans med tidsnumret möjliggör entydig avkodning, så att korrekt POSIX-tidsnummer kan genereras om så önskas, eller så kan hela UTC-tiden lagras i ett lämpligare format.

Den avkodningslogik som krävs för att klara av denna typ av Unix-klocka skulle också korrekt avkoda en hypotetisk POSIX-anpassad klocka med samma gränssnitt. Detta skulle uppnås genom att indikera TIME_INS-tillståndet under hela en insatt skottsekund, sedan indikera TIME_WAIT under hela den följande sekunden samtidigt som sekundräkningen upprepas. Detta kräver synkron språngsekundhantering. Detta är förmodligen det bästa sättet att uttrycka UTC-tid i Unix-klockform, via ett Unix-gränssnitt, när den underliggande klockan är fundamentalt obesvärad med skottsekunder.

Variant som räknar skottsekunder

En annan, mycket sällsyntare, icke-överensstämmande variant av Unix-tidshållning innebär att man ökar värdet för alla sekunder, inklusive skottsekunder; vissa Linux-system är konfigurerade på detta sätt. Tid som hålls på detta sätt kallas ibland för "TAI" (även om tidsstämplar kan konverteras till UTC om värdet motsvarar en tidpunkt då skillnaden mellan TAI och UTC är känd), i motsats till "UTC" (även om inte alla UTC-tidsvärden har en unik referens i system som inte räknar skottsekunder).

Eftersom TAI inte har några skottsekunder, och varje TAI-dag är exakt 86400 sekunder lång, är denna kodning faktiskt ett rent linjärt antal sekunder som förflutit sedan 1970-01-01T00:00:10 TAI. Detta gör tidsintervallaritmetiken mycket lättare. Tidsvärden från dessa system lider inte av den oklarhet som strikt överensstämmande POSIX-system eller NTP-drivna system har.

I dessa system är det nödvändigt att konsultera en tabell med skottsekunder för att korrekt konvertera mellan UTC och pseudo-Unix-tidsrepresentationen. Detta liknar det sätt på vilket tidszonstabeller måste konsulteras för att konvertera till och från civil tid ; IANAs tidszonsdatabasen innehåller språngsekundinformation, och exempelkoden som är tillgänglig från samma källa använder den informationen för att konvertera mellan TAI-baserade tidsstämplar och lokal tid. Konvertering stöter också på definitionsproblem före 1972 års början av den nuvarande formen av UTC (se avsnittet UTC-grunden nedan).

Detta system, trots sin ytliga likhet, är inte Unix-tid. Den kodar tider med värden som skiljer sig med flera sekunder från POSIX-tidsvärdena. En version av detta system, där epoken var 1970-01-01T00:00:00 TAI snarare än 1970-01-01T00:00:10 TAI, föreslogs för inkludering i ISO C:s time.h , men bara UTC-delen accepterades 2011. En tai_clock finns dock i C++20.

Representerar numret

Ett Unix-tidsnummer kan representeras i vilken form som helst som kan representera tal. I vissa applikationer representeras numret helt enkelt textmässigt som en sträng av decimalsiffror, vilket endast ger upphov till triviala ytterligare problem. Vissa binära representationer av Unix-tider är dock särskilt betydelsefulla.

Unix time_t som representerar en tidpunkt är, på många plattformar, ett heltal med tecken , traditionellt på 32 bitar (men se nedan), som direkt kodar Unix-tidsnumret enligt beskrivningen i föregående avsnitt. Att vara 32 bitar innebär att den täcker ett intervall på cirka 136 år totalt. Minsta representativa datum är fredagen 1901-12-13, och det maximala representerbara datumet är tisdag 2038-01-19. En sekund efter 03:14:07 UTC 2038-01-19 kommer denna representation att svämma över i det som kallas år 2038-problemet .

I vissa nyare operativsystem har time_t utökats till 64 bitar. Detta utökar de tider som kan representeras med cirka 292 miljarder år i båda riktningarna, vilket är över tjugo gånger universums nuvarande ålder per riktning.

Det fanns ursprungligen en del kontroverser om huruvida Unix time_t skulle signeras eller osigneras. Om det inte är signerat, skulle dess räckvidd i framtiden fördubblas, vilket skjuter upp 32-bitars spill (med 68 år). Men den skulle då vara oförmögen att representera tider före epoken. Konsensus är att time_t ska undertecknas, och detta är den vanliga praxisen. Programvaruutvecklingsplattformen för version 6 av QNX -operativsystemet har en osignerad 32-bitars time_t , även om äldre versioner använde en signerad typ.

POSIX- och Open Group Unix-specifikationerna inkluderar C-standardbiblioteket , som inkluderar tidstyperna och funktionerna som definieras i rubrikfilen < time.h> . ISO C-standarden säger att time_t måste vara en aritmetisk typ, men kräver inte någon specifik typ eller kodning för den. POSIX kräver att time_t är en heltalstyp, men kräver inte att den ska signeras eller osigneras.

Unix har ingen tradition av att direkt representera icke-heltals Unix-tidsnummer som binära bråk. Istället representeras tider med sub-sekunders precision med hjälp av sammansatta datatyper som består av två heltal, det första är en time_t (den integrerade delen av Unix-tiden), och den andra är bråkdelen av tidstalet i miljondelar (i miljondelar). struct timeval ) eller miljarddelar (i struct timespec ). Dessa strukturer ger ett decimalbaserat dataformat med fast punkt, vilket är användbart för vissa applikationer, och trivialt att konvertera för andra .

UTC-bas

Den nuvarande formen av UTC, med skottsekunder, definieras först från och med den 1 januari 1972. Dessförinnan, sedan den 1 januari 1961, fanns det en äldre form av UTC där det inte bara fanns enstaka tidssteg, som inte var heltal. antal sekunder, men även UTC-sekunden var något längre än SI-sekunden och ändrades periodvis för att kontinuerligt approximera jordens rotation. Före 1961 fanns det ingen UTC, och före 1958 fanns det ingen utbredd atomär tidmätning ; i dessa epoker användes en viss approximation av GMT (baserat direkt på jordens rotation) istället för en atomär tidsskala. ^{[ citat behövs ]}

Den exakta definitionen av Unix-tid som en kodning av UTC är bara okontroversiell när den tillämpas på den nuvarande formen av UTC. Unix-epoken som föregick starten av denna form av UTC påverkar inte dess användning i denna era: antalet dagar från 1 januari 1970 (Unix-epoken) till 1 januari 1972 (starten av UTC) är inte ifrågasatt, och antal dagar är allt som har betydelse för Unix-tiden.

Innebörden av Unix-tidsvärden under +63 072 000 (dvs före 1 januari 1972) är inte exakt definierad. Grunden för sådana Unix-tider förstås bäst som en ospecificerad approximation av UTC. Datorer från den eran hade sällan klockor inställda tillräckligt noggrant för att ge meningsfulla tidsstämplar under sekunden i alla fall. Unix-tid är inte ett lämpligt sätt att representera tider före 1972 i applikationer som kräver precision på undersekund; sådana applikationer måste åtminstone definiera vilken form av UT eller GMT de använder.

Från och med 2009 övervägs möjligheten att avsluta användningen av skottsekunder i civil tid. Ett troligt sätt att verkställa denna förändring är att definiera en ny tidsskala, kallad International Time ^{[ citation needed ]} , som initialt matchar UTC men som därefter inte har några skottsekunder, och som därmed förblir på en konstant offset från TAI. Om detta händer, är det troligt att Unix-tiden kommer att definieras prospektivt i termer av denna nya tidsskala, istället för UTC. Osäkerhet om huruvida detta kommer att inträffa gör den framtida Unix-tiden inte mindre förutsägbar än den redan är: om UTC helt enkelt inte skulle ha några fler skottsekunder skulle resultatet bli detsamma.

Historia

De tidigaste versionerna av Unix-tid hade ett 32-bitars heltal som steg med en hastighet av 60 Hz , vilket var hastigheten för systemklockan på hårdvaran i de tidiga Unix-systemen. Värdet 60 Hz visas fortfarande i vissa programvarugränssnitt som ett resultat. ^{Så sent .} som i november 1971 räknade Unix fortfarande tiden i 60-delar av en sekund sedan en epok den 1 januari 1971, vilket är ett år senare än den epok som används för närvarande Denna tidsstämpel kunde bara representera ett intervall på cirka 2,5 år, vilket tvingade epok och enheter som räknas att omdefinieras; den tredje upplagan av UNIX-manualen specificerar en epok av 1 januari 1972. Tidiga definitioner av Unix-tid saknade också tidszoner.

Den nuvarande epoken 1 januari 1970 00:00:00 UTC valdes godtyckligt av Unix-ingenjörer eftersom det ansågs vara ett lämpligt datum att arbeta med. Precisionen ändrades för att räkna i sekunder för att undvika kortvarig översvämning.

När POSIX.1 skrevs uppstod frågan om hur man exakt definierar time_t inför skottsekunder. POSIX-kommittén övervägde om Unix-tid skulle förbli, som avsett, ett linjärt antal sekunder sedan epoken, på bekostnad av komplexiteten i omvandlingar med civil tid eller en representation av civil tid, på bekostnad av inkonsekvens runt skottsekunder. Tidens datorklockor var inte tillräckligt exakt inställda för att bilda ett prejudikat på ett eller annat sätt.

POSIX-kommittén styrdes av argument mot komplexitet i biblioteksfunktionerna, ^{[ citat behövs ]} och definierade bestämt Unix-tiden på ett enkelt sätt i termer av elementen i UTC-tid. Denna definition var så enkel att den inte ens omfattade hela skottårsregeln i den gregorianska kalendern, och skulle göra 2100 till ett skottår.

2001 års upplaga av POSIX.1 rättade till den felaktiga skottårsregeln i definitionen av Unix-tid, men behöll den väsentliga definitionen av Unix-tid som en kodning av UTC snarare än en linjär tidsskala. Sedan mitten av 1990-talet har datorklockor rutinmässigt ställts in med tillräcklig precision för att detta ska ha betydelse, och de har oftast ställts in med den UTC-baserade definitionen av Unix-tid. Detta har resulterat i avsevärd komplexitet i Unix-implementeringar, och i Network Time Protocol , för att exekvera steg i Unix-tidsnumret närhelst skottsekunder inträffar. ^{[ citat behövs ]}

Begränsningar

Unix-tid har utformats för att koda kalenderdatum och tider på ett kompakt sätt avsett att användas av datorer internt. Det är inte avsett att vara lätt att läsa av människor eller att lagra tidszonsberoende värden. Den är också som standard begränsad till att representera tid i sekunder, vilket gör den olämplig för användning när en mer exakt tidsmätning behövs, till exempel när man mäter programkörningstiden.

Utbud av representativa tider

Unix-tid genom design kräver ingen specifik storlek för lagringen, men de vanligaste implementeringarna av Unix-tid använder ett signerat heltal med ordstorleken för den underliggande datorn. Eftersom majoriteten av moderna datorer är 32-bitars eller 64-bitars , och ett stort antal program fortfarande skrivs i 32-bitars kompatibilitetsläge, betyder detta att många program som använder Unix-tid använder signerade 32-bitars heltalsfält. Det maximala värdet för ett signerat 32-bitars heltal är 2 ³¹ -1, och minimivärdet är -(2 ³¹ ), vilket gör det omöjligt att representera datum före 13 december 1901 (kl. 20:45:52 UTC) eller efter 19 januari , 2038 (kl. 03:14:07 UTC). Den tidiga cutoffen kan ha en inverkan på databaser som lagrar historisk information; i vissa databaser där 32-bitars Unix-tid används för tidsstämplar, kan det vara nödvändigt att lagra tid i en annan form av fält, till exempel en sträng, för att representera datum före 1901. Den sena cutoff är känd som År 2038- problemet och har potential att orsaka problem när datumet närmar sig, eftersom datum efter gränsen 2038 skulle gå tillbaka till början av det representativa intervallet 1901.

64-bitars lagring av Unix-tid antas i allmänhet inte ha problem med datumintervallsbegränsningar, eftersom det effektiva datumintervallet som kan representeras med Unix-tid lagrad i ett signerat 64-bitars heltal är över 584 miljarder år, eller cirka 42 gånger större än universums nuvarande beräknade ålder.

Alternativ

Unix-tid är inte den enda standarden för tid som räknas bort från en epok. På Windows lagrar typen FILETIME tid som ett antal 100-nanosekundersintervaller som har förflutit sedan 0:00 GMT den 1 januari 1601; den används för att lagra tidsstämplar för filer och används i vissa protokoll som primärt, men inte uteslutande, används på Windows-datorer, såsom Active Directory Time Service}} och Server Message Block- protokollen. Network Time Protocol som används för att koordinera tid mellan datorer använder en epok från 1 januari 1900, räknat i ett osignerat 32-bitars heltal i sekunder och ett annat osignerat 32-bitars heltal för bråkdelssekunder, som rullar över var 2:e 32:e sekund (ungefär ^en gång vart 136:e år).

Många applikationer och programmeringsspråk tillhandahåller metoder för att lagra tid med en explicit tidszon. Det finns också ett antal tidsformatstandarder som finns för att kunna läsas av både människor och datorer, såsom ISO 8601 .

Anmärkningsvärda händelser i Unix-tid

Unix-entusiaster har en historia av att hålla "time_t parties" (uttalas "time tea parties ") för att fira betydande värden för Unix-tidsnumret. Dessa är direkt analoga med nyårsfirandet som inträffar vid årsskiftet i många kalendrar. I takt med att användningen av Unix-tid har spridit sig, har bruket att fira dess milstolpar också ökat. Vanligtvis är det tidsvärden som är runda tal med decimaler som firas, enligt Unix-konventionen att visa time_t -värden i decimaltal. Bland vissa grupper hyllas också runda binära tal, såsom +2 ³⁰ som inträffade kl. 13:37:04 UTC lördagen den 10 januari 2004. ^{[ citat behövs ]}

Händelserna som dessa firar beskrivs vanligtvis som " N sekunder sedan Unix-epoken", men detta är felaktigt; som diskuterats ovan, på grund av hanteringen av skottsekunder i Unix-tid antalet sekunder som förflutit sedan Unix-epoken är något större än Unix-tidstalet för tider senare än epoken.

Kl. 18:36:57 UTC onsdagen den 17 oktober 1973 ägde det första datumet upp i ISO 8601- format (1973-10-17) inom Unix-tidens siffror (119731017).
Klockan 01:46:40 UTC söndagen den 9 september 2001 firades Unix billennium (Unix tid nummer 1 000 000 000 ). Namnet millennium är en portmanteau av miljarder och millennium . Vissa program som lagrade tidsstämplar med hjälp av en textrepresentation stötte på sorteringsfel, som i en textsortering, gånger efter omsättningen med 1 siffra , felaktigt sorterade före tidigare tider med 9 siffror. Berörda program inkluderar den populära Usenet- läsaren KNode och e-postklienten KMail , en del av KDE:s skrivbordsmiljö. Sådana buggar var i allmänhet kosmetiska till sin natur och fixades snabbt när problemen blev uppenbara. Problemet påverkade också många Filtrix -dokumentformatfilter som tillhandahålls med Linux -versioner av WordPerfect ; en patch skapades av användargemenskapen för att lösa detta problem, eftersom Corel inte längre sålde eller stödde den versionen av programmet.
Kl. 23:31:30 UTC fredagen den 13 februari 2009 nådde decimalrepresentationen av Unix-tid 1 234 567 890 sekunder . Google firade detta med en Google doodle . Fester och andra firanden hölls runt om i världen, bland olika tekniska subkulturer, för att fira den 1 234 567 890 :e sekunden.
Kl 09:06:49 UTC fredagen den 16 juni 2034 kommer Unix-tidsvärdet att vara lika med aktuellt år, månad, datum och timme (2034061609). ^{[ citat behövs ]}
Tisdagen den 19 januari 2038 kl. 03:14:08 UTC kommer 32-bitarsversioner av Unix-tidsstämpeln att sluta fungera, eftersom det kommer att svämma över det största värdet som kan hållas i ett signerat 32-bitars nummer ( 7FFFFFFF 16 eller 2 147 483 647 ). Innan detta ögonblick kommer programvara som använder 32-bitars tidsstämplar att behöva anta en ny konvention för tidsstämplar, och filformat som använder 32-bitars tidsstämplar kommer att behöva ändras för att stödja större tidsstämplar eller en annan epok. Om den är oförändrad kommer nästa sekund att felaktigt tolkas som 20:45:52 fredag 13 december 1901 UTC . Detta kallas år 2038-problemet .
Kl. 06:28:15 UTC söndagen den 7 februari 2106 kommer Unix-tiden att nå FFFFFFFF 16 eller 4 294 967 295 sekunder, vilket, för system som håller tiden på 32-bitars heltal utan tecken, är det maximala uppnåbara. För vissa av dessa system kommer nästa sekund att felaktigt tolkas som 00:00:00 torsdag 1 januari 1970 UTC . Andra system kan uppleva ett spillfel med oförutsägbara utfall. ^{[ citat behövs ]}
Kl 15:30:08 UTC söndagen den 4 december 292 277 026 596 kommer Unix-tiden att svämma över det största värdet som kan hållas i ett signerat 64-bitars nummer. Denna varaktighet är nästan 22 gånger den uppskattade nuvarande åldern för universum , vilket är 1,37 × 10 ¹⁰ (13,7 miljarder) år.

I populärkulturen

Vernor Vinges roman A Deepness in the Sky beskriver en rymdfarande handelscivilisation tusentals år i framtiden som fortfarande använder Unix-epoken. " programmeraren-arkeologen " som ansvarar för att hitta och underhålla användbar kod i mogna datorsystem tror först att epoken syftar på den tid då människan först gick på månen, men inser sedan att det är "0-sekunden av en av mänsklighetens första datoroperativsystem".

Se även

Anteckningar

externa länkar

Unix Programmerarmanual, första upplagan
Personlig redogörelse för POSIX-besluten av Landon Curt Noll
kronokompatibla lågnivådatumalgoritmer – algoritmer för att konvertera mellan gregorianska och julianska datum och antalet dagar sedan starten av Unix-tiden