Szilveszteri szökőmásodperc

A hetvenes evek ota 32-szer kellett korrigalni? Nem gondoltam volna,
hogy ilyen gyors utemben lassul a Fold forgasa.

Nem vagyok benne biztos, hogy csak ez van emogott ... Hanem mert ugye a Fold nap koruli utja (tehat egy ev hossza) es egy nap hossznak hanyadosa nem egesz szam, ezt mindenki tudja, ezert van szokoev stb. Csakhogy a hanyados tortesze sem egeszen .25, azaz szukseg van ennel bonyolultabb korrekciora is, stb stb ... Bar mondjuk ha ilyen gyakran kell ilyen kis idoket korrigalni akkor nem tudom ... A Fold forgasnak lassulasa meg ha jol tudom osszefugg a Hold palyajanak valtozasaval is valahol, dehogy ez nem a "tervezett" :) utemben zajlana azt nem tudom. De majd valaki okos biztos tudja mi a gixer itt most ...

a tengely körüli forgás, és a nap körüli keringés nincs szinkronban. ezért van négyévente szököév, de a 100-al oszthatók közül csak a 400-al oszthatók szököévek, de még így sem pontos a dolog.

Viszont amióta atomórák vannak, a maradék eltérést inkább apránként "dolgozzák le", nem várják be, amíg egy teljes nap különbség lesz belőle.

Mészáros András wrote:
> a tengely körüli forgás, és a nap körüli keringés nincs szinkronban. ezért
> van négyévente szököév, de a 100-al oszthatók közül csak a 400-al oszthatók
> szököévek, de még így sem pontos a dolog.
>
> Viszont amióta atomórák vannak, a maradék eltérést inkább apránként
> "dolgozzák le", nem várják be, amíg egy teljes nap különbség lesz belőle.

Hoppa, ez kiment a fejembol, igazatok van.

Bugfix a cikkhez: eddig nem 32, hanem 22 szökőmásodperc volt, ez lesz tehát a huszonharmadik.

A POSIX szabvány szerint a Unix rendszerek belső (kernel) órája egy referencia időpillanat (ez az ún. Epoch: 1970. jan. 1. 0 óra 0 perc 0 mp UTC) óta eltelt _nem szökőmásodperceket_ számolja, így hiába volt azóta 22 szökőmásodperc, most is minden egész órakor osztható 3600-zal az értéke. A Unix rendszerek tehát elhanyagolják, mondhatni "összecsalják" azt a plusz másodpercet, nyilván az ntp vagy valami hasonló mechanizmus korrigálni fogja az 1mp csúszást. A felhasználó tehát ilyen felállás mellett nem találkozik 60-as mp értékkel.

Általában telepítve vannak azok az időzóna fájlok is, melyek akkor lennének helyesek, ha a kernel idő az összes másodpercet, vagyis a szökőmásodperceket is tartalmazná, vagyis ha most épp 22-vel nagyobb lenne a helyes értéke, mint amennyi. Ezek az időzónák helye (általában /usr/share/zoneinfo) alatt a right könyvtár, szemben a posix könyvtárral.

Példa 16 óra 30 perc 22 mp-kor:

egmont@bobek:~$ TZ=Europe/Budapest date; TZ=right/Europe/Budapest date

2005. júl. 21., csütörtök, 16.30.22 CEST

2005. júl. 21., csütörtök, 16.30.00 CEST

Tehát a posix adatbázishoz (defaulthoz) képest a "right" használata 22 mp-vel kevesebbet ír ki, mivel ő azt feltételezi, hogy a kernel órája 22 mp-cel előrébb jár, mint a "posix" esetben. (Akinek elsőre az előjel nem triviális, az gondolja végig még egyszer, jó ez így. A right változat nagyobb kernel értékre számít, miközben a valós idő ugyanannyi, ezért él abban a tévhitben, hogy 22 mp-cel korábbi időpont van, mint ami ténylegesen.)

Az UHU-ban megtalálható, egyébként freshmeat-ről is letölthető timeslide progival illusztrálva:

egmont@bobek:~$ while sleep 0.5; do TZ=right/Europe/Budapest TIMESLIDE=-206807890 timeslide date; done

1999. jan. 1., péntek, 00.59.58 CET

1999. jan. 1., péntek, 00.59.58 CET

1999. jan. 1., péntek, 00.59.59 CET

1999. jan. 1., péntek, 00.59.59 CET

1999. jan. 1., péntek, 00.59.60 CET

1999. jan. 1., péntek, 00.59.60 CET

1999. jan. 1., péntek, 01.00.00 CET

1999. jan. 1., péntek, 01.00.00 CET

1999. jan. 1., péntek, 01.00.01 CET

1999. jan. 1., péntek, 01.00.01 CET

1999. jan. 1., péntek, 01.00.02 CET

1999. jan. 1., péntek, 01.00.02 CET

Tehát a megfelelő glibc függvények és standard GNU utility-k fel vannak készítve a 60. másodperc lehetőségére. A most év végén esedékes szökőmásodpercről természetesen a glibc adatbázisa még nem tud, hiszen mostanság egyre ritkábbak a szökőmásodpercek.

Megjegyzendő az is, hogy a szökőmásodperc greenwich-i idő szerint éjfélkor, tehát nálunk egy óráva az újév beköszönte után esedékes.

>Hoppa, ez kiment a fejembol, igazatok van.

kozben gondolkodtam. nem irtam teljesen igazat:)

ket kulon dolog van:

1. elcsuszik a dél. tehát Greenich-ben amikor delel a nap, akkor az atomórák pl: 12:00:01-et mutatnak. ezt lehet(kell) korrigálni a kicsi eltérésekkel. ezt az okozza, hogy tömegeket mozgatunk a földön, és emiatt változik a Föld tehetetlenségi nyomatéka. A hold által keltett árapály is hosszabtávon hatással a van a Föld forgására.

2. nem egész számu többszöröse az nap körüli keringés pontos ifeje a föld forgási idejének. ez csak szőkőnapokkal korrigálható. A 100-as mégseszökönap szabály pontatlansága miatt asszem 3000 évente kell még egy extra szökönapot beiktatni, de ráérünk, az utolsó naptárreform nem olyan régen volt, mindössze 500 éve:) van még időnk:)

A cikkben említett korrekciókra a világidő és a koordinált világidő közti eltérések miatt van szükség. Mindkét időt atomórákkal mérik és a koordinált időt igazítják 0,7 (más források szerint 0,9) másodperces eltérések esetén a világidőhöz. A bolygó tengelyforgásának sebessége valóban változik -- főleg az árapályerők hatására -- ez azonban sokkal kisebb mértékű változás: évente körülbelül 0,0029 másodpercre tehető.

A világidő egyébként a 0 hosszúsági körhöz tartozó középszoláris idő. A középszoláris idő pedig a fiktív egyenlítői középnap óraszöge plusz 12 óra. Fiktív egyenlítői középnapnak nevezzük azt a pontot, mely egyenletes szögsebességgel megy végig az égi egyenlítőn, az út befutásához pedig annyi időre van szüksége, mint a fiktív ekliptikai középnapnak az ekliptika befutásához és a fiktív ekliptikai középnappal a tavaszpontban egyezik meg. És így tovább még egy darabig, amíg valódi fizikai jelenségekig eljutunk :).

Egy rövid és velős összefoglaló olvasható a wikipedia-n is:

http://en.wikipedia.org/wiki/Utc

Üdv,

bog

Koszi, ez hasznos volt.

Megnéztem a php5-ben a time() kimenete alapján (SuSE 9.3):

1136069999 - 2005. dec. 31., szombat, 23.59.59 CET

1136070000 - 2006. jan. 1., vasárnap, 00.00.00 CET

1136070001 - 2006. jan. 1., vasárnap, 00.00.01 CET

Így vmiért nem veszi figyelembe. Bár az is lehet, hogy nem számolja hozzá a szökőmásodpercet.

1 év = 365,2422 nap, ezért:

-4 évente +1 nap

-100 évente -1 nap

-400 évente +1 nap

-Sygma

> Nem lehet valamilyen függvénnyel leírni ezt?

Szerintem azért nem, mert itt a Föld forgásának olyan nüansznyi eltéréseiről van szó, amit csak megfigyelni tudunk, előre következtetni már kevésbé. De ez csak tipp.

Lásd fenti hosszú hozzászólásomat. Nem a megfelelő időzóna adatbázist használod, de ha a megfelelőt használnád akkor is a vadiúj tzdata2005k verzióra lenne szükséged, ami kb. 1 hete jelent meg, és a glibc cvs még nem tartalmazza, továbbá rossz pillanatban is számítasz a jelenségre. Frissítsd adatbázisodat például a http://public.planetmirror.com/pub/timezone/ címről letölthető legújabb verzióra, Időzónának állítsd be a right/Europe/Budapest-et, a szökőmásodpercet pedig magyar idő szerint hajnali 1-kor keresd.

Ezt az amit szeretek a HUP kozossegeben.

Ennyi hozzaerto ember kozott mindig van legalabb 1, aki az adott temaval komolyabban foglalkozott, es meg leirni is hajlando:)