Zastrzeżenie:

Właśnie przeglądałem listę stron StackExchange przez około 20 minut, próbując dowiedzieć się, gdzie to opublikować. Jeśli znasz jakąś stronę bardziej odpowiednią, przenieś tam to pytanie. Zamieszczam to tutaj, ponieważ czas na uniks zmusił mnie do myślenia.

Jak wszyscy wiemy, istnieje czas uniksowy i UTC. Czas uniksowy wciąż tyka, odliczając sekundy - jedna sekunda na sekundę - podczas gdy UTC stara się utrzymywać czas w formatach czytelnych dla człowieka, które stosujemy zgodnie z fazą Ziemi podczas jej obrotu. Aby to zrobić, UTC wstawia od czasu do czasu sekundy przestępne.

Ponieważ czas jest zależny od siły grawitacji, na którą narażony jest obiekt, na inne rodzaje przyspieszenia i prędkości względnej, prowadzi to do dwóch pytań. Najpierw przejdźmy do prostej: gdzie mierzy się czas unixowy? Jeśli Alicja i Bob zaczną uzgadniać, że aktualny czas to 1467932496.42732894722748, kiedy znajdują się w tym samym miejscu (sekunda jest oczywiście zdefiniowana jako 9'192'631'770 cykli promieniowania odpowiadających przejściu między dwoma poziomami energii cezu-133 atom w spoczynku i przy 0 K), doświadczaj podwójnego paradoksu, ponieważ Alice mieszka na poziomie morza i Bob mieszka wysoko w górach lub Alice mieszka na biegunie północnym i Bob mieszka na równiku, nie będą już więcej zgodni. Jak dokładnie zdefiniowany jest czas unixowy?

Na początku możesz nie widzieć problemu z UTC, ponieważ z pewnością wszyscy mogą się zgodzić, kiedy Ziemia dokończy orbitę (jest to oczywiście ignorowanie ruchu płyty kontynentalnej, ale myślę, że dobrze ją zrozumieliśmy, ponieważ dzięki GPS można zmierzyć ich ruch bardzo dokładnie i możemy założyć, że znajdują się one w ustalonym położeniu w naszym modelu i nie poruszają się wraz z przesunięciem płyt kontynentalnych), bez względu na to, czy znajdują się na górze, na poziomie morza, na równiku, czy na biegunie północnym. Mogą występować pewne różnice czasowe, ale się nie kumulują.

Ale sekundę definiuje się jako 9'192'631'770 cykli promieniowania odpowiadających przejściu między dwoma poziomami energii atomu cezu-133 w spoczynku i przy 0 K i atomu cezu-133 nie dbają o orbitę ziemską. Tak więc UTC decyduje, gdzie wstawić sekundę przestępną, ale musi istnieć zmierzone lub przewidywane przesunięcie między fazą orbity Ziemi a czasem mierzonym gdzieś za pomocą zegara atomowego. Gdzie to gdzieś jest?

Twoje główne pytanie nie ma prawdziwej odpowiedzi; Czas uniksowy nie jest prawdziwą skalą czasu i nigdzie nie jest „mierzony”. Jest to reprezentacja UTC, choć słaba, ponieważ są w UTC momenty, których nie może reprezentować. Czas uniksowy nalega, aby każdego dnia było 86 400 sekund, ale UTC odbiega od tego z powodu sekund przestępnych.

Jeśli chodzi o twoje szersze pytanie, istnieją cztery ważne ramy czasowe zainteresowania:

1. UT1 (czas uniwersalny), który jest obliczany przez obserwatoria na całym świecie, które mierzą obrót Ziemi względem gwiazd nieruchomych. Dzięki tym spostrzeżeniom i odrobinie matematyki otrzymujemy bardziej nowoczesną wersję starego czasu środkowoeuropejskiego, opartego na momencie słonecznego południa w Królewskim Obserwatorium w Greenwich. Czas uniwersalny jest obliczany przez organizację o nazwie IERS (International Earth Rotation and Reference Systems Service, dawniej International Earth Rotation Service).

2. TAI (Międzynarodowy Czas Atomowy), który jest utrzymywany przez setki zegarów atomowych na całym świecie, utrzymywany przez krajowe organy normalizacyjne i tym podobne. Opiekunowie zegarów, które przyczyniają się do TAI, używają technik transferu czasu , aby kierować swoje zegary ku sobie nawzajem, znosząc wszelkie małe błędy poszczególnych zegarów i tworząc zbiór czasowy; tym zespołem jest TAI, opublikowane przez Międzynarodowe Biuro Miar i Wag (BIPM), stewardów systemu jednostek SI. Aby odpowiedzieć na twoje pytanie dotyczące dylatacji czasu, TAI jest zdefiniowane jako czas atomowy na poziomie morza (w rzeczywistości na geoidie, która jest bardziej wyrafinowaną wersją tego samego pomysłu), a każdy zegar koryguje wpływ swojej wysokości.

3. UTC (uniwersalny czas koordynowany). UTC ustawiono na dziesięć sekund za TAI 1 stycznia 1972 r. I od tej daty tyka do przodu z dokładnie taką samą szybkością jak TAI, z wyjątkiem sytuacji, gdy sekunda przestępna jest dodawana lub odejmowana. IERS podejmuje decyzję o ogłoszeniu drugiego skoku, aby utrzymać różnicę w ciągu 0,9 sekundy (w praktyce w ciągu około 0,6 sekundy; dodatkowy sekunda skoku powoduje zmianę różnicy z -0,6 na +0,4). Teoretycznie sekundy przestępne mogą być zarówno dodatnie, jak i ujemne, ale ponieważ obroty ziemi zwalniają w porównaniu ze standardem ustalonym przez SI i TAI, ujemna sekunda przestępna nigdy nie była konieczna i prawdopodobnie nigdy nie będzie.

4. Czas uniksowy, który najlepiej reprezentuje UTC jako pojedynczą liczbę. Każdy czas uniksowy będący wielokrotnością 86 400 odpowiada północy UTC. Ponieważ nie wszystkie dni UTC mają 86 400 sekund, ale wszystkie „dni uniksowe” są, istnieje niemożliwa do pogodzenia różnica, którą należy jakoś załatać. Nie ma czasu uniksowego odpowiadającego dodatkowemu sekundowi przestępnemu. W praktyce systemy będą działały tak, jakby poprzednia sekunda wystąpiła dwukrotnie (z uniksowym znacznikiem czasu przeskakuje do tyłu o jedną sekundę, a następnie znów do przodu), lub zastosuje technikę, taką jak rozmazywanie skoków, która wypacza czas na dłuższy czas po obu stronach sekunda przestępna. W obu przypadkach występuje pewna niedokładność, chociaż przynajmniej druga jest monotoniczna. W obu przypadkach,i b nie jest równe ba; jest równa ba plus liczba sekund przestępnych .

Ponieważ UT1, TAI, UTC i IERS są działaniami międzynarodowymi na całym świecie, nie ma jednego „gdzie”, chociaż biuletyny IERS są publikowane z Obserwatorium Paryskiego, a BIPM ma również siedzibę w Paryżu, to jedna odpowiedź. Organizacja, która wymaga dokładnego, możliwego do śledzenia czasu, może określić swoją podstawę czasu jako coś w rodzaju „UTC (USNO)”, co oznacza, że ​​ich znaczniki czasu są w UTC i że pochodzą z czasu w Obserwatorium Marynarki Wojennej USA, ale biorąc pod uwagę problemy, które: Wspomniałem o czasie uniksowym, jest on zasadniczo niezgodny z tym poziomem precyzji - każdy, kto ma do czynienia z naprawdę precyzyjnym czasem, będzie miał alternatywę dla czasu uniksowego.

Korekty zegara są koordynowane przez IERS. W zależności od potrzeb planują wstawienie sekundy przestępnej do strumienia czasu.

Z harmonogramu NTP i sekund przestępnych

Międzynarodowy Obrót Obsługa Ziemia (IERS) w Obserwatorium Paryskim wykorzystuje obserwacje astronomiczne dostarczonych przez USNO i innych obserwatoriów określić UT1 ramy czasowe (nawigatora) skorygowany o nieregularnych zmian w rotacji Ziemi.

Według mojej najlepszej wiedzy 23:59:60 (Skok drugi) i 00:00:00 następnego dnia są uważane za tę samą sekundę w Czasie Uniksowym.

Czas w systemie UNIX jest mierzony na komputerze z systemem UNIX.

Ta odpowiedź oczekuje, że będziesz wiedział, co to jest uniwersalny czas Coördinated (UTC), międzynarodowy czas atomowy (TAI) i sekunda SI. Wyjaśnienie ich znacznie wykracza poza zakres Unix i Linux Stack Exchange. To nie jest wymiana stosów fizyki ani astronomii.

Sprzęt

Twój komputer zawiera różne oscylatory, które napędzają zegary i timery. Dokładnie to, co ma, różni się w zależności od architektury w zależności od architektury. Ale zwykle i bardzo ogólnie:

• Gdzieś jest programowalny zegar interwałowy (PIT), który można zaprogramować tak, aby zliczał określoną liczbę oscylacji i wyzwalał przerwanie w centralnej jednostce przetwarzania.
• Na centralnym procesorze znajduje się licznik cykli, który po prostu zlicza 1 dla każdego wykonywanego cyklu instrukcji.

Teoria działania w bardzo szerokim ujęciu

Jądro systemu operacyjnego wykorzystuje PIT do generowania tików . Ustawia PIT na swobodny bieg, odliczając odpowiednią liczbę oscylacji w przedziale czasowym, powiedzmy, setnej sekundy, generując przerwanie, a następnie automatycznie resetując licznik, aby przejść ponownie. Istnieją różne warianty, ale w gruncie rzeczy powoduje to, że przerwanie tikowania jest podnoszone ze stałą częstotliwością.

W oprogramowaniu jądro zwiększa licznik co tyknięcie. Zna częstotliwość tykania, ponieważ w pierwszej kolejności zaprogramował PIT. Więc wie, ile tyknięć stanowi sekundę. Może to wykorzystać, aby wiedzieć, kiedy zwiększyć licznik, który liczy sekundy. To ostatnie jest pomysłem jądra na „UNIX Time”. Rzeczywiście po prostu liczy się w górę o jedną sekundę na sekundę SI, jeśli pozostawia się go własnym urządzeniom.

Komplikują to cztery rzeczy, które przedstawię bardzo ogólnie.

Sprzęt nie jest idealny. PIT, którego arkusz danych mówi, że ma częstotliwość oscylatora N Hertz, może zamiast tego mieć częstotliwość (powiedzmy) N .00002 Hertz, z oczywistymi konsekwencjami.

Ten schemat bardzo słabo współpracuje z zarządzaniem energią, ponieważ procesor budzi się setki razy na sekundę, aby zrobić niewiele więcej niż zwiększyć liczbę w zmiennej. Dlatego niektóre systemy operacyjne mają tak zwane „tykające” projekty. Zamiast zmuszać PIT do wysyłania przerwania dla każdego tiku, jądro oblicza (z poziomu niskiego poziomu harmonogramu), ile tików minie bez wyczerpania kwanty wątków, i programuje PIT, aby liczył tak wiele tików do przyszłość przed wydaniem przerwania kleszcza. Wie, że następnie musi zarejestrować przejście N tyknięć przy następnym przerwaniu tykania, zamiast 1 tyknięcia.

Oprogramowanie aplikacji może zmieniać aktualny czas jądra. To może zwiększyć wartość lub można go zabił wartość. Slewing polega na dostosowaniu liczby tyknięć, które muszą przejść, aby zwiększyć licznik sekund. Więc sekundy licznik nie musi liczyć w tempie jednego na drugi SI w każdym razie , nawet zakładając idealny oscylatorów. Stepping polega po prostu na wpisaniu nowej liczby w liczniku sekund, co zwykle nie nastąpi do 1 sekundy SI od ostatniej sekundy.

Nowoczesne jądra nie tylko liczą sekundy, ale także liczą nanosekundy. Ale przerywanie tyknięcia raz na nanosekundę jest śmieszne i często wręcz niemożliwe. W tym miejscu pojawiają się takie rzeczy, jak licznik cykli . Jądro pamięta wartość licznika cykli w każdej sekundzie (lub w każdym tiku) i może obliczyć, na podstawie bieżącej wartości licznika, gdy coś chce poznać czas w nanosekundach, ile nanosekund musiało upłynąć od ostatniej sekundy (lub kleszcz). Ponownie jednak zarządzanie energią i temperaturą powoduje spustoszenie, ponieważ częstotliwość cyklu instrukcji może się zmieniać, więc jądra polegają na dodatkowym sprzęcie, takim jak (powiedzmy) High Precision Event Timer (HPET).

Język C i POSIX

Biblioteka standardowa języka C opisuje czas pod względem nieprzezroczystego typu time_t, rodzaju konstrukcja tmz różnych określonych dziedzinach i różne funkcje, takie jak biblioteki time(), mktime()oraz localtime().

W skrócie: sam język C gwarantuje jedynie, że time_tjest jednym z dostępnych typów danych liczbowych i że jedynym niezawodnym sposobem obliczania różnic czasowych jest difftime()funkcja. Jest to standard POSIX, który zapewnia surowsze gwarancje, które time_tw rzeczywistości są jednym z typów całkowitych i liczą sekundy od Epoki . Jest to również standard POSIX, który określa timespectyp struktury.

time()Funkcja czasami określa się jako połączenie systemu. W rzeczywistości od dawna nie było to wywołanie systemowe wielu systemów. Na przykład we FreeBSD bazowe wywołanie systemowe clock_gettime()ma różne „zegary”, które mierzą w sekundach lub sekundach + nanosekundy na różne sposoby. Jest to wywołanie systemowe, za pomocą którego oprogramowanie aplikacji odczytuje czas UNIX z jądra. (Dopasowane clock_settime()wywołanie systemowe pozwala im wykonać krok, a adjtime()wywołanie systemowe pozwala im go zabić.)

Wiele osób macha standardem POSIX z bardzo określonymi i dokładnymi twierdzeniami na temat tego, co zaleca. Tacy ludzie najczęściej nie czytają standardu POSIX. Zgodnie z uzasadnieniem pomysł liczenia „sekund od epoki”, który jest zwrotem używanym przez standard, celowo nie określa, że ​​sekundy POSIX mają taką samą długość jak sekundy SI, ani że wynik gmtime()jest „koniecznie UTC, pomimo swojego wyglądu ”. Standard POSIX jest celowona tyle luźne, że pozwala (powiedzmy) systemowi UNIX, w którym administrator idzie i ręcznie naprawia drobne korekty, ustawiając ponownie zegar tydzień po ich wystąpieniu. W rzeczywistości uzasadnienie wskazuje, że jest celowo wystarczająco luźny, aby pomieścić systemy, w których zegar został celowo ustawiony nieprawidłowo na inny czas niż bieżący czas UTC.

UTC i TAI

Interpretacja czasu UNIX uzyskanego z jądra zależy od procedur bibliotecznych działających w aplikacjach. POSIX określa tożsamość między czasem jądra a „czasem awarii” w pliku struct tm. Ale, jak kiedyś zauważył Daniel J. Bernstein, wydanie standardu z 1997 r. Wprowadziło tę zawstydzająco błędną tożsamość, zaburzając zasadę roku przestępnego w kalendarzu gregoriańskim (coś, czego uczą się uczniowie), tak że obliczenia były błędne od roku 2100. „Więcej honoru w naruszeniu niż w przestrzeganiu” to zdanie, które przychodzi mi do głowy.

I rzeczywiście tak jest. Wiele systemów obecnie opiera tę interpretację na procedurach bibliotecznych napisanych przez Arthura Davida Olsona, które sprawdzają niesławną „bazę danych stref czasowych Olsona”, zwykle zakodowaną w plikach bazy danych /usr/share/zoneinfo/. System Olson miał dwa tryby:

• Uważa się, że „sekundy od epoki” jądra liczą sekundy UTC od 1970-01-01 00:00:00 UTC, z wyjątkiem sekund przestępnych. Wykorzystuje posix/zestaw plików bazy danych strefy czasowej Olson. Wszystkie dni mają 86400 sekund jądra i nigdy nie ma 61 sekund na minutę, ale nie zawsze mają one długość sekundy SI, a zegar jądra wymaga obracania lub stopniowania, gdy występują sekundy przestępne.
• Uważa się, że „sekundy od epoki” jądra liczą sekundy TAI od 1970-01-01 00:00:10 TAI. Wykorzystuje right/zestaw plików bazy danych strefy czasowej Olson. Sekundy jądra mają długość 1 sekundy SI, a zegar jądra nigdy nie potrzebuje zmiany ani kroku, aby dostosować się do sekund przestępnych, ale czasy awarii mogą mieć wartości takie jak 23:59:60, a dni nie zawsze wynoszą 86400 sekund jądra.

M. Bernstein napisał kilka narzędzi, w tym swój daemontoolszestaw narzędzi, które były wymagane, right/ponieważ po prostu dodali 10, time_taby uzyskać sekundy TAI od 1970-01-01 00:00:00 TAI. Udokumentował to na stronie podręcznika.

Wymóg ten (być może nieświadomie) został odziedziczony przez zestawy narzędzi, takie jak daemontools-encorei runitFelixa von Leitnera libowfat. Na przykład użyj Bernsteinamultilog , Guenteramultilog lub Pape'asvlogd z posix/konfiguracją Olsona , a wszystkie znaczniki czasu TAI64N będą (w chwili pisania tego tekstu) 26 sekund za faktyczną drugą liczbą TAI od 1970-01-01 00:00:10 TAI.

Laurent Bercot i ja zajęliśmy się tym w s6 i nosh, choć przyjęliśmy inne podejście. M. Bercot tai_from_sysclock()opiera się na flagi czasu kompilacji. Narzędzia nosh, które działają w TAI64N, sprawdzają zmienne środowiskowe TZi, TZDIRaby automatycznie wykryć posix/i right/jeśli potrafią.

Co ciekawe, dokumenty time2posix()i posix2time()funkcje FreeBSD, które pozwalają na ekwiwalent right/trybu Olson z time_tsekundami TAI. Jednak najwyraźniej nie są one włączone.

Jeszcze raz…

Czas w systemie UNIX jest mierzony na komputerze z systemem UNIX za pomocą oscylatorów zawartych w sprzęcie komputera. Nie używa sekund SI; to nie jest UTC, nawet jeśli powierzchownie może go przypominać; i celowo pozwala na to, aby Twój zegar się mylił.

Dalsza lektura

• Daniel J. Bernstein. Czas UTC, TAI i UNIX . cr.yp.to.
• Daniel J. Bernstein. tai64nlocal. daemontools. cr.yp.to.
• „ sekundy od epoki ”. Pojedyncza specyfikacja UNIX, wersja 2 . 1997. The Open Group.
• „ Seconds Since the Epoch (Rationale) ”. Podstawowe specyfikacje Wydanie 6 . 2004. IEEE 1003.1. Grupa otwarta.
• David Madore (2010-12-17). Uniksowy drugi bałagan .
• time2posix. Podręcznik FreeBSD 10.3. § 3
• /physics/45739/
• /astronomy/11840/