Unix-tid ( engelska Unix-tid , även POSIX-tid ) är ett system för att beskriva ögonblick i tid, antaget i Unix och andra POSIX -kompatibla operativsystem . Definierat som antalet sekunder sedan midnatt (00:00:00 UTC ) 1 januari 1970 (torsdag); detta ögonblick kallas "Unix Epoch" ( eng. Unix Epoch ).
Unix-tiden representeras av ett heltal som ökar för varje sekund som går utan att det behövs beräkningar för att fastställa år, månad, dag, timme eller minut för mänsklig läsbarhet. Modern Unix-tid överensstämmer med UTC - nedräkningen är i SI sekunder . Tidsspannet för en dag är nästan alltid uppdelat i 86 400 sekunder , men när skottsekunder deklareras är det 86 401 sekunder . Sådana sekunder håller enligt Universal Time längden på dagarna synkroniserade med tiden för planetens revolution. I Unix-tid upprepas motsvarande sekundsiffror, dvs skottsekunder räknas inte.
Klockan 00:00:00 UTC den 1 januari 1970 (torsdag) är Unix-tiden noll. Från och med denna tidpunkt ökar antalet med en viss mängd per dag. Således, till exempel, den 16 september 2004 kl. 00:00:00, 12677 dagar efter att Unix-tiden började, skulle tiden vara 12677 × 86400 = 1095292800 , eller i fallet med den 17 december 2003 kl. 00:00:00 12403 dagar efter starten av nedräkningen kommer tiden att vara talet 12403 × 86400 = 1 071 619 200 . Beräkningar kan också göras omvänt med negativa tal. Till exempel, datumet 4 oktober 1957 00:00:00, vilket är 4472 dagar före start av nedräkningen, representeras i Unix-tid av talet −4472 × 86400 = −386380800 [1] .
Varje dag beräknas siffran som representerar Unix-tid enligt beskrivningen i UTC (00:00:00Z), och ökar exakt 1 per sekund från midnatt . Därför kommer tidpunkten 16-09-2004 17:55:43.54 , motsvarande 64 543,54 sekunder från midnatt på detta datum, från exemplet ovan, att representeras i Unix-tid med talet 1 095 292 800 + 64 543,54 = 3,54 = 3,54 . För datum som föregår början av nedräkningen ökar också antalet, det vill säga med tiden närmar det sig noll [2] .
Heltalssystemet som används är bekvämt att använda för att jämföra och lagra datum (datum och tid i detta format tar bara 4 eller 8 byte ). Om du behöver hänvisa till datumelement (dag, månad, år) kan sekunder konverteras till vilket lämpligt format som helst (och vice versa).
Program använder den signerade heltalstypen för att lagra Unix - tid . Signerade 32-bitars nummer kan hänvisa till tider från fredagen den 13 december 1901, 20:45:52 till tisdagen den 19 januari 2038, 03:14:07 inklusive.
För att få aktuell Unix-tid på de flesta Unix-liknande system kan du använda kommandot date +%s .
Minsta datum i signerad 32-bitars notation är 13 december 1901 , 20:45:52 UTC (0x80000000, −2 147 483 648 sekunder från 1 januari 1970).
Ett potentiellt kritiskt datum var 9 september 2001 , 01:46:40 UTC , motsvarande en gigasekund (miljarder sekunder) Unix-tid, då teckendecimalrepresentationen översteg 9 positioner, vilket kan påverka funktionen hos vissa medicinska applikationer [3] .
Det viktigaste kritiska datumet ur Unix-tidens synvinkel är den 19 januari 2038 kl. 03:14:08 UTC, då värdet på en variabel av typen som time_träknar antalet sekunder som förflutit sedan 1 januari 1970 når 2 31 , vilket kan leda till en felaktig tolkning av denna siffra som negativ . Komplexet av risker som är förknippat med detta datum har kallats problemet 2038 . En möjlig lösning på detta problem är att inte använda en 32 -bitars , utan en 64-bitars variabel för att lagra tid (vilket görs i alla moderna 64-bitars operativsystem), detta kommer att räcka i 292 miljarder år [4] .
Apples 64-bitars iOS - enheter har ett problem som ett Unix-system: om du ställer in tiden på en 64-bitars iOS-enhet till ett på morgonen den 1 januari 1970 och startar om enheten medan du befinner dig i tidszonen från UTC + 1:30 och mer, sedan efter omstart av enheten kommer den inte att slås på, Apple-logotypen kommer ständigt att visas på skärmen. Detta händer på grund av skillnaden i tidszoner, det vill säga: om du översätter tiden till 1:00 den 1 januari 1970 i tidszonen UTC +1:30 eller mer, så går Unix-tidsräknaren i minus, vilket systemet kan inte förstå , eftersom nedräkningen är från UTC, vilket gör att enheten fryser. Enheten återställs inte via DFU, men problemet har två lösningar på andra sätt. Det första sättet: vänta tills telefonens batteri tar slut helt och själva räknaren nollställs. Det andra sättet: plocka isär enheten och koppla bort batteriet ett tag, sätt sedan ihop enheten igen, räknaren återställs också till noll och enheten kommer att fungera.
Problemet är äntligen löst i iOS 9.3.1 [5] - nu är det möjligt att ställa in datumet på enheten från och med 1 januari 2001.