TAI->UTC->GMT (Re: Letni a zimni cas)

Michal Dobes dobes na tesnet.cz
Úterý Říjen 29 16:48:05 CET 2002


"Ing. Pavel PaJaSoft Janousek" wrote:
>         Dekuji vsem za dalsi rozsireni obzoru, prece jen se jiz nejakou
> petiletku astronomii nezabyvam vice nez nekolikere kouknuti na krasnou
> nocni oblohu...:-)

Ja kdyz byl malej, naivni a blbej (nejsem si jist, ktere body uz 
prestaly platit), tak jsem chtel byt namornikem. :-)

> 1. Proc pri instalaci (napr. Red Hat Linuxu) je volba casove zony a
> nasledne, zda-li cas v CMOS je v UTC nebo v lokalnim case? Jak jsem
> pochopil zavery ostatnich diskutujicich, je to ve skutecnosti oboji
> uplna blbost, protoze co se tomu nejvice blizi muze byt maximalne GCT -
> lide, stejne jako casovac na MB (v PC) si 30.6. ani 31.12. neposouvaji
> hodinky o dvojsekundu, ani se nedozvidaji vysledek comitetu (IERS)...:-)

Odpovim otazkou, proc se casto vyskytuje oznaceni hacker tam, kde
by melo byt slovo cracker? Je to v podstate stejna uroven problemu,
zvyk je zelezna kosile. :-)
Korektni oznaceni by IMHO melo byt UTC+0 nebo GMT+0, cimz je receno,
od jakeho normalu racite odvozovat svuj PC cas (a ten jde stejne
sejdrem, vetsina RTC obvodu se drzi na urovni 1 s/den, horsi 5 s/den). 

> 2. Jak se presne meri TAI, pripadne jak se zjisti, ze mame chybu?
> Dokazal nekdo odhalit nepresnost treba v atomovych hodinach, ktere to
> meri a nebo nas TAI cas je cas, ktery si myslime (lidstvo), ze merime
> presne? Jak se da ta chyba poznat - z nebeske kinematiky ne, tam je
> nepresnosti vice, jakou vztaznou soustavu tedy mame dale na vyber
> (polocas rozpadu nejakych castic, spektralni analyza prvku...?)?

"Bezne" meritelna rozlisitelnost TAI casu se udava 10^-9. Je to dano
frekvenci zdroje zareni zmineneho Cesia 133 cca 9*10^-9 Hz.
Predpoklada se, ze vysledna chyba TAI casu neni vetsi, nez 
0.1 mikrosekundy/rok.
Cas se stanovuje dohodou z tech 200 hodin zapojenych do systemu.
Zdroje vykazujici extremni odchylky se likviduji (statistika tomu
rika ocisteni ciselne rady?).
Zminena komis vydava pravidelne prehledy kde je napsano co a jak 
a jaky je dle nich spravny vysledek. :-)
Cas odvozeny od GMT ma mit rozlisovaci schopnost na urovni 
milisekund.

> 3. Vim, ze se uvadi, ze presnost atomovych hodin je takova makova,
> nicmene nikdo netvrdi, ze je 100% presna, jak tedy tu nepresnost
> eliminovat, podle ceho, jaky je absolutni rozdil a jak ho ziskat?

Vychazi se z SI, ktere reklo, jak dlouho sekunda trva a za jakych 
podminek a dal je to statistika. :-)
 
> 4. Merim-li cas, resp. jsem pasivni prijimac napr. systemem Network Time
> Protocol, jak se do serveru se stratum 0 podsunou vysledky IERS ci
> jinych korekci - mysleno |TAI - UTC| - domnivam se, ze vetsina je S0 je
> pripojena na GPS ci radiove systemy, tudiz se ridi UTC casem, krasa, ale
> to jsme furt skoro o sekundu (potencialne) jinde...:-)?

Pravda je takova, ze tyto "lepsi" systemy tento rozdil znaji. Stejne
tak u systemu GPS je aktualni stav TAI-UTC soucasti prenasene
casove informace ze satelitu. 
U slusnejsih GPS systemu primarne k mereni casu a ne polohy je to
nastavitelne, zda vas zajima i na vystupu k vam UTC nebo TAI.

V pripade NTP je tam flag, ze bude prestupna sekunda. Toto se dozvi
od daneho zdroje, ze se tak stane (obvykle se to signalizuje hodinu
dopredu). Samozrejme musi NTP akceptovat, ze ze zdroje prijde
cas 23:59:60, pripadne i 23:59:61 (nebo naopak i min).
Pokud system toto nedokaze rozdychat, tak NTP to pak dokorigije 
zrychlenim/zpomalenim.

Pavel Kankovsky wrote:
> V praxi je to na unixovych systemech tak, ze se tvari, ze pocitaji sekundy
> od urciteho pocatecniho okamziku, ale zaroven chteji drzet krok s UTC,
> jenze pro prestupne sekundy pouzivaji pstrosi politiku a proste je
> ignoruji. Vysledek je takovy, ze unixovy systemovy cas je proste
> priblizne pocet UTC dni od pocatku epochy nasobeny 86400, pricemz fakt,
> ze nektere UTC dny maji 86401 sekund, se schova do celkove nepresnosti
> hodin.

Ano, unixiky podle POSIX.1 maji vnitrne cas jako pocet sekund od 
1.1.1970 0:0:0 s tim, ze kazdy ctvrty rok je prestupny a prestupne
sekuny se neuvazuji (tohle je cas vyjadreny v datovem typu time_t).
Pri konverzi na cas mistni se prepocitava vse, co prepocitat jde.
Takze zahrnout i prestupne sekundy by mohlo jit dle tabulky, 
ale nejsem si jist, zda se tim libc zabyva (doufam, ze aspon
spravne pocita prestupne roky /4 ano, /100 ne, /400 ano,
/3600 ne). :-)

	Majkl


Další informace o konferenci Linux