Czas uniksowy

Bieżący czas systemu Unix 1679180815 () 2023-03-18T23:06:55+00:00

Czas systemu Unix minął 1 000 000 000 sekund w dniu 2001-09-09T01:46:40Z. Święto obchodzono w Kopenhadze w Danii na przyjęciu zorganizowanym przez duńską Grupę Użytkowników UNIX o godzinie 03:46:40 czasu lokalnego.

Czas uniksowy to reprezentacja daty i czasu szeroko stosowana w informatyce . Mierzy czas na podstawie liczby sekund , które upłynęły od godziny 00:00:00 czasu UTC 1 stycznia 1970 r., początku ery Uniksa , pomniejszonej o poprawki wprowadzone z powodu sekund przestępnych .

Czas uniksowy powstał jako czas systemowy systemów operacyjnych Unix . Jest szeroko stosowany w innych komputerowych systemach operacyjnych , systemach plików , językach programowania i bazach danych .

Definicja

Dwie warstwy kodowania składają się na czas uniksowy. Pierwsza warstwa koduje punkt w czasie jako skalarną liczbę rzeczywistą , która reprezentuje liczbę sekund, które upłynęły od godziny 00:00:00 UTC w czwartek, 1 stycznia 1970 r. Druga warstwa koduje tę liczbę jako sekwencję bitów lub cyfr dziesiętnych .

Czas uniksowy różni się zarówno od uniwersalnego czasu koordynowanego (UTC), jak i międzynarodowego czasu atomowego (TAI) w obsłudze sekund przestępnych . UTC obejmuje sekundy przestępne, które dostosowują się do rozbieżności między dokładnym czasem mierzonym przez zegary atomowe , a czasem słonecznym , odnoszącym się do położenia Ziemi względem Słońca. Międzynarodowy czas atomowy (TAI), w którym każdy dzień ma dokładnie 86 400 sekund, ignoruje czas słoneczny i stopniowo traci synchronizację z obrotem Ziemi w tempie mniej więcej jednej sekundy na rok. W czasie uniksowym każdy dzień zawiera dokładnie 86 400 sekund, ale uwzględniane są sekundy przestępne. Każda sekunda przestępna używa sygnatury czasowej sekundy, która bezpośrednio ją poprzedza lub następuje.

Kodowanie czasu jako liczby

Czas uniksowy to pojedyncza liczba ze znakiem, która zwiększa się co sekundę, co ułatwia komputerom przechowywanie i manipulowanie niż konwencjonalne systemy daty. Programy tłumacza mogą następnie przekonwertować go do formatu czytelnego dla człowieka.

Epoka Unix .; to czas 00:00:00 UTC w dniu 1 stycznia 1970 r. Jest problem z tą definicją, ponieważ UTC nie istniało w swojej obecnej formie aż do 1972 r ten problem jest omówiony poniżej. Dla zwięzłości pozostała część tej sekcji używa formatu daty i godziny ISO 8601 , w którym epoka systemu Unix to 1970-01-01T00:00:00Z.

Numer czasu Uniksa wynosi zero w epoce Uniksa i wzrasta dokładnie o 86 400 dziennie od tej epoki. Tak więc 2004-09-16T00:00:00Z, 12 677 dni po epoce, jest reprezentowane przez numer czasu systemu Unix 12 677 × 86 400 = 1 095 292 800 . Można to również rozszerzyć wstecz od epoki, używając liczb ujemnych; tak więc 1957-10-04T00:00:00Z, 4472 dni przed epoką, jest reprezentowane przez numer czasu Uniksa −4472 × 86 400 = −386 380 800 . Dotyczy to również dni; numer czasu o dowolnej porze dnia to liczba sekund, które upłynęły od północy rozpoczynającej się tego dnia, dodana do numeru czasu tej północy.

Czasami czas uniksowy jest błędnie określany jako czas epoki , ponieważ czas uniksowy jest oparty na epoce i z powodu powszechnego nieporozumienia, że epoka uniksowa jest jedyną epoką (często nazywaną „ epoką ”).

Sekundy przestępne

Powyższy schemat oznacza, że w normalny dzień UTC, który trwa 86 400 sekund, numer czasu Unix zmienia się w sposób ciągły przez całą północ. Na przykład na koniec dnia użytego w powyższych przykładach reprezentacje czasu postępują w następujący sposób:

Czas uniksowy od północy do 17 września 2004 r. (bez sekundy przestępnej)
TAI (17 września 2004)	UTC (od 16 do 17 września 2004 r.)	Czas uniksowy
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

Kiedy pojawia się sekunda przestępna , dzień UTC nie ma dokładnie 86 400 sekund, a numer czasu w systemie Unix (który zawsze zwiększa się dokładnie o 86 400 każdego dnia) doświadcza nieciągłości . Sekundy przestępne mogą być dodatnie lub ujemne. Nigdy nie zadeklarowano żadnej ujemnej sekundy przestępnej, ale gdyby tak się stało, to na koniec dnia z ujemną sekundą przestępną numer czasu Uniksa podskoczyłby o 1 do początku następnego dnia. Podczas dodatniej sekundy przestępnej na koniec dnia, która ma miejsce średnio co półtora roku, liczba czasu systemu Unix wzrasta w sposób ciągły do następnego dnia podczas sekundy przestępnej, a następnie na koniec sekundy przestępnej cofa się o 1 (wracając do początku następnego dnia). Na przykład tak się stało w systemach ściśle zgodnych z POSIX.1 pod koniec 1998 roku:

Czas uniksowy od północy do 1 stycznia 1999 r. (dodatnia sekunda przestępna)
TAI (1 stycznia 1999)	UTC (od 31 grudnia 1998 do 1 stycznia 1999)	Czas uniksowy
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

Liczby czasu systemu Unix są powtarzane w sekundzie bezpośrednio po dodatniej sekundzie przestępnej. Uniksowy numer czasu 1 483 142 400 jest więc niejednoznaczny: może odnosić się albo do początku sekundy przestępnej (2016-12-31 23:59:60), albo do jej końca, sekundę później (2017-01-01 00 :00:00). W teoretycznym przypadku, gdy pojawia się ujemna sekunda przestępna, nie ma dwuznaczności, ale zamiast tego istnieje zakres liczb czasu Unix, które w ogóle nie odnoszą się do żadnego punktu w czasie UTC.

Zegar uniksowy jest często implementowany z innym typem obsługi dodatniej sekundy przestępnej, związanym z protokołem Network Time Protocol (NTP). Daje to system, który nie jest zgodny ze standardem POSIX. Szczegółowe informacje znajdują się w poniższej sekcji dotyczącej NTP.

W przypadku okresów, które nie obejmują sekundy przestępnej UTC, różnica między dwoma numerami czasu w systemie Unix jest równa długości okresu w sekundach między odpowiednimi punktami w czasie. Jest to powszechna technika obliczeniowa. Jednak tam, gdzie występują sekundy przestępne, takie obliczenia dają błędną odpowiedź. W aplikacjach, w których wymagany jest ten poziom dokładności, konieczne jest zapoznanie się z tabelą sekund przestępnych, gdy mamy do czynienia z czasami uniksowymi, i często preferowane jest użycie innego kodowania czasu, które nie ma tego problemu.

Numer czasu Unix można łatwo przekonwertować z powrotem na czas UTC, biorąc iloraz i moduł numeru czasu Unix, modulo 86 400 . Iloraz to liczba dni, które upłynęły od epoki, a moduł to liczba sekund, które upłynęły od północy czasu UTC w tym dniu. Jeśli podano numer czasu Unix, który jest niejednoznaczny z powodu dodatniej sekundy przestępnej, ten algorytm interpretuje go jako czas tuż po północy. Nigdy nie generuje czasu, który jest w sekundzie przestępnej. Jeśli podano numer czasu Unix, który jest nieprawidłowy z powodu ujemnej sekundy przestępnej, generuje równie nieprawidłowy czas UTC. Jeśli te warunki są znaczące, konieczne jest zapoznanie się z tabelą sekund przestępnych, aby je wykryć.

Niesynchroniczny wariant oparty na protokole czasu sieciowego

Zwykle zegar uniksowy w stylu Millsa jest implementowany z obsługą sekundy przestępnej niezsynchronizowanej ze zmianą liczby czasu w systemie Unix. Numer czasu początkowo zmniejsza się w miejscu, w którym powinien nastąpić przeskok, a następnie przeskakuje do właściwego czasu 1 sekundę po przeskoku. Ułatwia to implementację i jest opisane w artykule Millsa. Oto, co dzieje się w dodatniej sekundzie przestępnej:

Niesynchroniczny zegar Unix w stylu Millsa od północy do 1 stycznia 1999 r. (Dodatnia sekunda przestępna)
TAI (1 stycznia 1999)	UTC (od 31 grudnia 1998 do 1 stycznia 1999)	Państwo	Zegar uniksowy
1999-01-01T00:00:29.75	1998-12-31T23:59:58.75	CZAS_INS	915 148 798 .75
1999-01-01T00:00:30.00	1998-12-31T23:59:59.00	CZAS_INS	915 148 799 00
1999-01-01T00:00:30.25	1998-12-31T23:59:59.25	CZAS_INS	915 148 799 .25
1999-01-01T00:00:30.50	1998-12-31T23:59:59.50	CZAS_INS	915 148 799 .50
1999-01-01T00:00:30.75	1998-12-31T23:59:59.75	CZAS_INS	915 148 799 .75
1999-01-01T00:00:31.00	1998-12-31T23:59:60.00	CZAS_INS	915 148 800 .00
1999-01-01T00:00:31.25	1998-12-31T23:59:60.25	CZAS_OOP	915 148 799 .25
1999-01-01T00:00:31.50	1998-12-31T23:59:60.50	CZAS_OOP	915 148 799 .50
1999-01-01T00:00:31.75	1998-12-31T23:59:60.75	CZAS_OOP	915 148 799 .75
1999-01-01T00:00:32.00	1999-01-01T00:00:00.00	CZAS_OOP	915 148 800 .00
1999-01-01T00:00:32.25	1999-01-01T00:00:00.25	CZAS OCZEKIWANIA	915 148 800 .25
1999-01-01T00:00:32.50	1999-01-01T00:00:00.50	CZAS OCZEKIWANIA	915 148 800 .50
1999-01-01T00:00:32.75	1999-01-01T00:00:00.75	CZAS OCZEKIWANIA	915 148 800 .75
1999-01-01T00:00:33.00	1999-01-01T00:00:01.00	CZAS OCZEKIWANIA	915 148 801 00
1999-01-01T00:00:33.25	1999-01-01T00:00:01.25	CZAS OCZEKIWANIA	915 148 801 .25

Można to odpowiednio zdekodować, zwracając uwagę na zmienną stanu sekundy przestępnej, która jednoznacznie wskazuje, czy skok został już wykonany. Zmiana zmiennej stanu jest synchroniczna ze skokiem.

Podobna sytuacja ma miejsce w przypadku ujemnej sekundy przestępnej, gdzie sekunda, która jest pomijana, jest nieco za późno. Bardzo krótko system pokazuje nominalnie niemożliwą liczbę czasu, ale może to zostać wykryte przez stan TIME_DEL i skorygowane.

W tego typu systemie numer czasu Unix narusza POSIX wokół obu typów sekundy przestępnej. Zbieranie zmiennej stanu sekundy przestępnej wraz z liczbą czasu pozwala na jednoznaczne dekodowanie, więc w razie potrzeby można wygenerować poprawny numer czasu POSIX lub pełny czas UTC można zapisać w bardziej odpowiednim formacie.

Logika dekodowania wymagana do radzenia sobie z tym stylem zegara uniksowego również poprawnie dekodowałaby hipotetyczny zegar zgodny z POSIX przy użyciu tego samego interfejsu. Można to osiągnąć poprzez wskazanie stanu TIME_INS przez całą wstawioną sekundę przestępną, a następnie wskazanie TIME_WAIT przez całą następną sekundę, powtarzając odliczanie sekund. Wymaga to obsługi synchronicznej sekundy przestępnej. Jest to prawdopodobnie najlepszy sposób wyrażenia czasu UTC w postaci zegara uniksowego, za pośrednictwem interfejsu uniksowego, gdy podstawowy zegar jest zasadniczo wolny od sekund przestępnych.

Wariant, który liczy sekundy przestępne

Inny, znacznie rzadszy, niezgodny wariant utrzymywania czasu w systemie Unix obejmuje zwiększanie wartości dla wszystkich sekund, w tym sekund przestępnych; niektóre systemy Linux są konfigurowane w ten sposób. Czas utrzymywany w ten sposób jest czasami określany jako „TAI” (chociaż znaczniki czasu można przekonwertować na UTC, jeśli wartość odpowiada czasowi, w którym znana jest różnica między TAI a UTC), w przeciwieństwie do „UTC” (chociaż nie wszystkie Wartości czasu UTC mają unikalne odniesienie w systemach, które nie liczą sekund przestępnych).

Ponieważ TAI nie ma sekund przestępnych, a każdy dzień TAI ma dokładnie 86400 sekund, to kodowanie jest w rzeczywistości czystą liniową liczbą sekund, które upłynęły od 1970-01-01T00:00:10 TAI. To znacznie ułatwia arytmetykę przedziałów czasowych. Wartości czasu z tych systemów nie są tak niejednoznaczne, jak systemy ściśle zgodne z POSIX lub systemy oparte na NTP.

W tych systemach konieczne jest zapoznanie się z tabelą sekund przestępnych, aby poprawnie przekonwertować między czasem UTC a reprezentacją czasu pseudouniksowego. Przypomina to sposób, w jaki należy sprawdzać tabele stref czasowych, aby przeliczyć czas na iz czasu cywilnego ; baza danych stref czasowych IANA zawiera informacje o sekundach przestępnych, a przykładowy kod dostępny z tego samego źródła wykorzystuje te informacje do konwersji między znacznikami czasu opartymi na TAI a czasem lokalnym. Konwersja napotyka również problemy definicyjne przed wprowadzeniem obecnej formy UTC w 1972 r. (Patrz sekcja Podstawa UTC poniżej).

System ten, pomimo powierzchownego podobieństwa, nie jest czasem uniksowym. Koduje czasy z wartościami, które różnią się o kilka sekund od wartości czasu POSIX. Wersja tego systemu, w której epoka to 1970-01-01T00:00:00 TAI zamiast 1970-01-01T00:00:10 TAI, została zaproponowana do włączenia do ISO C time.h , ale tylko część UTC został zaakceptowany w 2011 roku. Tai_clock istnieje jednak w C++ 20.

Reprezentowanie liczby

Numer czasu systemu Unix może być reprezentowany w dowolnej formie zdolnej do reprezentowania liczb. W niektórych aplikacjach liczba jest po prostu reprezentowana tekstowo jako ciąg cyfr dziesiętnych, co powoduje jedynie trywialne dodatkowe problemy. Jednak niektóre binarne reprezentacje czasów uniksowych są szczególnie znaczące.

Uniksowy typ danych time_t , który reprezentuje punkt w czasie, jest na wielu platformach liczbą całkowitą ze znakiem , tradycyjnie 32- bitową (ale patrz poniżej), bezpośrednio kodującą liczbę czasu uniksowego, jak opisano w poprzedniej sekcji. Bycie 32-bitowym oznacza, że obejmuje łącznie około 136 lat. Minimalna możliwa do przedstawienia data to piątek 13.12.1901, a maksymalna możliwa do przedstawienia data to wtorek 19.01.2038. Sekundę po 03:14:07 UTC 2038-01-19 ta reprezentacja przepełni się w tak zwanym problemie roku 2038 .

W niektórych nowszych systemach operacyjnych time_t został rozszerzony do 64 bitów. Wydłuża to reprezentowalny czas o około 292 miliardy lat w obu kierunkach, czyli ponad dwudziestokrotnie więcej niż obecny wiek wszechświata w każdym kierunku.

Pierwotnie istniały pewne kontrowersje dotyczące tego, czy uniksowy time_t powinien być podpisany, czy nie. Gdyby nie był podpisany, jego zakres w przyszłości zostałby podwojony, odkładając 32-bitowe przepełnienie (o 68 lat). Jednak nie byłby wtedy w stanie przedstawiać czasów poprzedzających epokę. Konsensus polega na podpisaniu time_t i jest to zwykła praktyka. Platforma programistyczna dla wersji 6 systemu operacyjnego QNX ma 32-bitowy time_t bez znaku , chociaż starsze wersje używały typu ze znakiem.

POSIX i Open Group Unix zawierają standardową bibliotekę C , która zawiera typy czasu i funkcje zdefiniowane w pliku nagłówkowym <time.h> . Norma ISO C stwierdza, że time_t musi być typem arytmetycznym, ale nie określa dla niego żadnego określonego typu ani kodowania. POSIX wymaga, time_t był liczbą całkowitą, ale nie wymaga, aby był on podpisany lub niepodpisany.

Unix nie ma tradycji bezpośredniego przedstawiania niecałkowitych uniksowych liczb czasowych jako ułamków binarnych. Zamiast tego czasy z dokładnością poniżej sekundy są reprezentowane przy użyciu złożonych typów danych składających się z dwóch liczb całkowitych, z których pierwsza to time_t (cała część czasu systemu Unix), a druga to ułamkowa część liczby czasu w milionowych częściach (w struct timeval ) lub bilionowych (w struct timespec ). Struktury te zapewniają stały punkt dziesiętny format danych, który jest przydatny dla niektórych aplikacji i banalny do konwersji dla innych.

podstawie czasu UTC

Obecna forma UTC, z sekundami przestępnymi, jest definiowana dopiero od 1 stycznia 1972 r. Wcześniej, od 1 stycznia 1961 r. Istniała starsza forma UTC, w której nie tylko występowały sporadyczne przedziały czasowe, które były niecałkowite liczby sekund, ale także sekunda UTC była nieco dłuższa niż sekunda w układzie SI i okresowo zmieniana, aby w sposób ciągły przybliżać obrót Ziemi. Przed rokiem 1961 nie było czasu UTC, a przed rokiem 1958 nie było rozpowszechnionego atomowego pomiaru czasu ; w tych epokach zamiast atomowej skali czasu stosowano pewne przybliżenie GMT (oparte bezpośrednio na obrocie Ziemi). ^{[ potrzebny cytat ]}

Dokładna definicja czasu uniksowego jako kodowania UTC jest niekontrowersyjna tylko wtedy, gdy stosuje się ją do obecnej formy UTC. Epoka uniksowa poprzedzająca początek tej formy UTC nie wpływa na jej użycie w tej erze: liczba dni od 1 stycznia 1970 (epoka Unix) do 1 stycznia 1972 (początek UTC) nie jest kwestionowana, a liczba dni to wszystko, co ma znaczenie dla czasu uniksowego.

Znaczenie wartości czasu uniksowego poniżej +63 072 000 (tj. przed 1 stycznia 1972 r.) nie jest dokładnie określone. Podstawę takich czasów uniksowych najlepiej rozumieć jako nieokreślone przybliżenie czasu UTC. Komputery z tamtej epoki rzadko miały zegary ustawione wystarczająco dokładnie, aby w każdym razie zapewnić znaczące znaczniki czasu poniżej sekundy. Czas uniksowy nie jest odpowiednim sposobem przedstawiania czasów przed 1972 rokiem w aplikacjach wymagających dokładności poniżej sekundy; takie aplikacje muszą przynajmniej określać, jakiej formy UT lub GMT używają.

Od 2009 roku rozważana jest możliwość zaprzestania stosowania sekund przestępnych w czasie cywilnym. Prawdopodobnym sposobem wprowadzenia tej zmiany jest zdefiniowanie nowej skali czasu, zwanej czasem międzynarodowym ^{[ potrzebne źródło ]} , która początkowo odpowiada UTC, ale potem nie ma sekund przestępnych, pozostając w ten sposób na stałym przesunięciu od TAI. Jeśli tak się stanie, jest prawdopodobne, że czas uniksowy zostanie prospektywnie zdefiniowany w kategoriach tej nowej skali czasu, zamiast UTC. Niepewność co do tego, czy tak się stanie, sprawia, że przyszły czas uniksowy jest nie mniej przewidywalny niż już jest: gdyby UTC po prostu nie miało dalszych sekund przestępnych, wynik byłby taki sam.

Historia

Najwcześniejsze wersje czasu Unix miały 32-bitową liczbę całkowitą zwiększającą się z częstotliwością 60 Hz , co było częstotliwością zegara systemowego na sprzęcie wczesnych systemów Unix. W rezultacie wartość 60 Hz nadal pojawia się w niektórych interfejsach oprogramowania. ^{[ potrzebne źródło ]} Jeszcze w listopadzie 1971 r. Unix wciąż odliczał czas w 60. sekundy od epoki 1 stycznia 1971 r., czyli o rok później niż obecnie używana epoka. Ten znacznik czasu mógł reprezentować tylko zakres około 2,5 roku, zmuszając epokę i liczone jednostki do ponownego zdefiniowania; podręcznik UNIX do trzeciego wydania określa epokę 1 stycznia 1972 r. Wczesne definicje czasu uniksowego również nie zawierały stref czasowych.

Bieżąca epoka 1 stycznia 1970 00:00:00 UTC została wybrana arbitralnie przez inżynierów Uniksa, ponieważ uznano ją za dogodną datę do pracy. Precyzja została zmieniona na zliczanie w sekundach, aby uniknąć krótkotrwałego przepełnienia.

Kiedy pisano POSIX.1 , pojawiło się pytanie, jak precyzyjnie zdefiniować time_t w obliczu sekund przestępnych. Komitet POSIX zastanawiał się, czy czas uniksowy powinien pozostać, zgodnie z zamierzeniami, liniową liczbą sekund od epoki, kosztem złożoności konwersji z czasem cywilnym lub reprezentacją czasu cywilnego, kosztem niespójności wokół sekund przestępnych. Zegary komputerowe tamtej epoki nie były wystarczająco precyzyjnie ustawione, aby stworzyć precedens w taki czy inny sposób.

Komitet POSIX został przekonany argumentami przeciwko złożoności funkcji bibliotecznych ^{[ potrzebne źródło ]} i mocno zdefiniował czas uniksowy w prosty sposób, używając elementów czasu UTC. Ta definicja była tak prosta, że nie obejmowała nawet całej roku przestępnego kalendarza gregoriańskiego i czyniła rok 2100 rokiem przestępnym.

Wydanie POSIX.1 z 2001 roku poprawiło wadliwą regułę roku przestępnego w definicji czasu uniksowego, ale zachowało podstawową definicję czasu uniksowego jako kodowania UTC, a nie liniowej skali czasu. Od połowy lat 90. zegary komputerowe były rutynowo ustawiane z wystarczającą precyzją, aby miało to znaczenie, i najczęściej były ustawiane przy użyciu definicji czasu uniksowego opartej na UTC. Doprowadziło to do znacznej złożoności implementacji systemu Unix oraz protokołu Network Time Protocol w celu wykonywania kroków w numerze czasu systemu Unix za każdym razem, gdy występują sekundy przestępne. ^{[ potrzebne źródło ]}

Ograniczenia

Czas uniksowy został zaprojektowany do kodowania dat i godzin kalendarzowych w zwarty sposób, przeznaczony do użytku wewnętrznego przez komputery. Nie jest przeznaczony do łatwego odczytywania przez ludzi ani do przechowywania wartości zależnych od strefy czasowej. Jest również domyślnie ograniczony do przedstawiania czasu w sekundach, przez co nie nadaje się do użycia, gdy potrzebny jest dokładniejszy pomiar czasu, na przykład podczas pomiaru czasu wykonywania programów.

Zakres reprezentowalnych czasów

Czas uniksowy z założenia nie wymaga określonego rozmiaru pamięci, ale większość typowych implementacji czasu uniksowego używa liczby całkowitej ze znakiem z rozmiarem słowa komputera bazowego. Ponieważ większość nowoczesnych komputerów jest 32-bitowych lub 64-bitowych , a duża liczba programów jest nadal zapisywana w 32-bitowym trybie zgodności, oznacza to, że wiele programów korzystających z czasu systemu Unix używa podpisanych 32-bitowych pól liczb całkowitych. Maksymalna wartość 32-bitowej liczby całkowitej ze znakiem to 2 ³¹ -1, a minimalna to -(2 ³¹ ), co uniemożliwia przedstawienie dat przed 13 grudnia 1901 r. (o 20:45:52 UTC) lub po 19 stycznia , 2038 (o 03:14:07 UTC). Wczesne odcięcie może mieć wpływ na bazy danych przechowujące informacje historyczne; w niektórych bazach danych, w których 32-bitowy czas uniksowy jest używany do znaczników czasu, może być konieczne przechowywanie czasu w polu innej postaci, takiej jak ciąg znaków, w celu przedstawienia dat sprzed 1901 r. Późne odcięcie jest znane jako Problem z rokiem 2038 i może powodować problemy w miarę zbliżania się daty, ponieważ daty wykraczające poza granicę 2038 cofnęłyby się do początku reprezentowalnego zakresu w 1901 roku.

Ogólnie przyjmuje się, że 64-bitowe przechowywanie czasu uniksowego nie ma problemów z ograniczeniami zakresu dat, ponieważ efektywny zakres dat reprezentowanych przez czas uniksowy przechowywany w 64-bitowej liczbie całkowitej ze znakiem wynosi ponad 584 miliardy lat, czyli około 42 razy więcej niż obecny szacowany wiek wszechświata.

Alternatywy

Czas uniksowy nie jest jedynym standardem czasu odliczanego od epoki. W systemie Windows typ FILETIME przechowuje czas jako liczbę 100-nanosekundowych interwałów, które upłynęły od 0:00 GMT 1 stycznia 1601; służy do przechowywania znaczników czasu dla plików i jest używany w niektórych protokołach używanych głównie, ale nie wyłącznie, na komputerach z systemem Windows, takich jak Active Directory Time Service}} i protokoły Server Message Block . Protokół czasu sieciowego używany do koordynowania czasu między komputerami wykorzystuje epokę 1 stycznia 1900, liczoną 32-bitową liczbą całkowitą bez znaku dla sekund i inną 32-bitową liczbą całkowitą bez znaku dla ułamków sekund, która przewija się co 2 32 sekundy (mniej więcej raz na 136 ^lat ) .

Wiele aplikacji i języków programowania zapewnia metody przechowywania czasu z wyraźną strefą czasową. Istnieje również szereg standardów formatu czasu, które są czytelne zarówno dla ludzi, jak i komputerów, takie jak ISO 8601 .

Godne uwagi wydarzenia w czasach Uniksa

Entuzjaści Unixa mają historię organizowania „imprez time_t” (wymawianych jako „ imprezy herbaciane w czasie ”), aby uczcić znaczące wartości liczby czasu Uniksa. Są one bezpośrednio analogiczne do Nowego Roku , które występują przy zmianie roku w wielu kalendarzach. Wraz z rozpowszechnieniem się czasu uniksowego rozpowszechniła się praktyka celebrowania jego kamieni milowych. Zwykle obchodzone są wartości czasu, które są liczbami okrągłymi w systemie dziesiętnym , zgodnie z konwencją systemu Unix, polegającą na wyświetlaniu wartości time_t w systemie dziesiętnym. Wśród niektórych grup okrągły binarny obchodzone są również liczby, takie jak +2 ³⁰ , które miało miejsce o godzinie 13:37:04 UTC w sobotę, 10 stycznia 2004 r. ^{[ Potrzebne źródło ]}

Wydarzenia, które świętują, są zwykle opisywane jako „ N sekund od epoki Uniksa”, ale jest to niedokładne; jak omówiono powyżej, ze względu na obsługę sekund przestępnych w czasie uniksowym, liczba sekund, które upłynęły od epoki uniksowej, jest nieco większa niż liczba czasu uniksowego dla czasów późniejszych niż epoka.

O godzinie 18:36:57 UTC w środę, 17 października 1973 roku, miało miejsce pierwsze pojawienie się daty w formacie ISO 8601 (1973-10-17) w obrębie cyfr czasu uniksowego (119731017).
świętowano billennium Unix (numer czasu Unix 1 000 000 000 ). Nazwa billennium to kontaminacja miliarda i tysiąclecia . _ Niektóre programy, które przechowywały znaczniki czasu przy użyciu reprezentacji tekstowej, napotykały błędy sortowania, jak w sortowaniu tekstowym, czasy po obrocie zaczynającym się od 1 cyfry błędnie sortowane przed wcześniejszymi czasami zaczynającymi się od 9 cyfr. Wśród programów, których dotyczy problem, znalazł się popularny czytnik Usenetu KNode i klient poczty e-mail KMail , część środowiska graficznego KDE . Takie błędy miały na ogół charakter kosmetyczny i były szybko naprawiane, gdy pojawiły się problemy. Problem dotyczył również wielu filtrów formatu dokumentów Filtrix , dostarczanych z wersjami programu WordPerfect dla systemu Linux ; społeczność użytkowników stworzyła poprawkę, aby rozwiązać ten problem, ponieważ firma Corel nie sprzedawała już ani nie obsługiwała tej wersji programu.
O godzinie 23:31:30 czasu UTC w piątek, 13 lutego 2009 r. dziesiętna reprezentacja czasu uniksowego osiągnęła 1 234 567 890 sekund. Google uczciło to doodlem Google . Na całym świecie, wśród różnych technicznych subkultur, odbywały się przyjęcia i inne uroczystości, aby uczcić 1 234 567 890. sekundę.
O godzinie 09:06:49 UTC w piątek, 16 czerwca 2034 r., wartość czasu systemu Unix będzie równa bieżącemu rokowi, miesiącowi, dacie i godzinie (2034061609). ^{[ potrzebne źródło ]}
O godzinie 03:14:08 UTC we wtorek, 19 stycznia 2038 r., 32-bitowe wersje znacznika czasu systemu Unix przestaną działać, ponieważ przepełni największą wartość, jaką można przechowywać w 32-bitowej liczbie ze znakiem ( 7FFFFFFFF 16 lub 2 147 483 647 ). Przed tym momentem oprogramowanie korzystające z 32-bitowych znaczników czasu będzie musiało przyjąć nową konwencję dotyczącą znaczników czasu, a formaty plików korzystające z 32-bitowych znaczników czasu będą musiały zostać zmienione, aby obsługiwały większe znaczniki czasu lub inną epokę. Jeśli nie ulegnie zmianie, następna sekunda zostanie błędnie zinterpretowana jako 20:45:52 piątek 13 grudnia 1901 UTC . Jest to określane jako Problem roku 2038 .
O godzinie 06:28:15 czasu UTC w niedzielę, 7 lutego 2106 r., czas uniksowy osiągnie FFFFFFFF 16 lub 4 294 967 295 sekund, co w przypadku systemów przechowujących czas na 32-bitowych liczbach całkowitych bez znaku jest maksymalną możliwą do osiągnięcia wartością. W przypadku niektórych z tych systemów następna sekunda będzie błędnie interpretowana jako 00:00:00 czwartek, 1 stycznia 1970 r. UTC . W innych systemach może wystąpić błąd przepełnienia z nieprzewidywalnymi skutkami. ^{[ potrzebne źródło ]}
O godzinie 15:30:08 UTC w niedzielę, 4 grudnia 292 277 026 596 , czas Unix przepełni największą wartość, jaką można przechowywać w 64-bitowej liczbie ze znakiem. Ten czas trwania jest prawie 22 razy większy niż szacowany obecny wiek wszechświata , który wynosi 1,37 × 10 ¹⁰ (13,7 miliarda) lat.

W kulturze popularnej

Powieść Vernora Vinge'a A Deepness in the Sky opisuje podróżującą w kosmos cywilizację handlową tysiące lat w przyszłość, która wciąż korzysta z epoki Uniksa. „ Programista-archeolog ” odpowiedzialny za odnajdywanie i utrzymywanie użytecznego kodu w dojrzałych systemach komputerowych najpierw uważa, że epoka odnosi się do czasu, kiedy człowiek po raz pierwszy stanął na Księżycu , ale potem zdaje sobie sprawę, że jest to „0-sekunda jednego z pierwszych w historii ludzkości systemy operacyjne komputerów”.

Zobacz też

Notatki

Linki zewnętrzne

Podręcznik programisty systemu Unix, pierwsze wydanie
Konto osobiste decyzji POSIX autorstwa Landona Curta Nolla
chrono-Compatible Low-Level Date Algorithms - algorytmy do konwersji między datami gregoriańskimi i juliańskimi oraz liczbą dni od początku czasu uniksowego