"A szökőmásodperc fogalmát a Nemzetközi Csillagászati Unió Brightonban tartott 1970-es ülésén fogadták el és akkor vezették be, amikor az atomórák használatával nyilvánvalóvá vált, hogy a Föld forgása nem egyenletes, és a csillagászati megfigyelésekből származó idő eltér az atomórák által számított időtől. A szökőmásodperc nemzetközi alkalmazása 1972. január 1-jével kezdődött." - forrás
A szökőmásodperc bevezetése óta 27 alkalommal iktattak be szökőmásodpercet, a mai napig az UTC 27 alkalommal frissült.
A számítógépes rendszerek nem viselték jól az elmúlt években a beiktatott szökőmásodperceket. A Meta (Facebook) mérnökei most azzal álltak elő, hogy dobni kéne a szökőmásodpercek beiktatását, az időt hagyni a 27. frissített állapoton, mert az egész több problémát okoz mint amennyi haszna van:
At Meta, we’re supporting an industry effort to stop future introductions of leap seconds and stay at a current level of 27. Introducing new leap seconds is a risky practice that does more harm than good, and we believe it is time to introduce new technologies to replace it.
[...]
As engineers at Meta, we are supporting a larger community push to stop the future introduction of leap seconds and remain at the current level of 27, which we believe will be enough for the next millennium.
Részletek itt.
- A hozzászóláshoz be kell jelentkezni
Hozzászólások
laposföldhívő detected
- A hozzászóláshoz be kell jelentkezni
Irjak, hogy a fo oka a szokomasodpercnek a sarki jegek periodikussaga, de a kozeljovoben ez akar -1 masodpercet is okozhatna. Naluk eddig is elnyujtottak 17 orara azt az egy masodpercet:
"More recently, it has become a common practice to “smear” a leap second by simply slowing down or speeding up the clock. There is no universal way to do this, but at Meta we smear the leap second throughout 17 hours, starting at 00:00:00 UTC based on the time zone data (tzdata) package content."
Kulonbozo GPS variansok is a sajat munkarendjuk szerint iktatjak be a szokomasodpercet, ami miatt diszkrepancia van a rendszerek kozott. Pl:
"Back in 2012, Reddit experienced a massive outage because of a leap second; the site was inaccessible for 30 to 40 minutes. This happened when the time change confused the high-resolution timer (hrtimer), sparking hyperactivity on the servers, which locked up the machines’ CPUs."
Szoval van baj is a szokomasodperccel, persze lehet csak a rossz/kenyelmes implementaciokkal, a koordinacio hianyaval.
- A hozzászóláshoz be kell jelentkezni
Hat, ezaz hogy igy is szamos megoldas letezhet a problemara. Egyreszt hogy eleve a gep oraja TAI-ban jar, es az UTC az csak egy offset. Ez kb egy olyan megoldas lenne ami a mezei mugli-szintu rendszereket kurvara nem erintene, ahol meg tenyleg szukseg van a precizitasra azok meg orulnek is hogy TAI-ban jaranak az orak es nem egyenletlenul (azaz UTC-ben). Masreszt meg az NTP mar egy joideje tovabbitja a szokomasodperceket is, van ra mod, lekerdezheto, megoszthato. Raadasul ugye tobb mint fel evvel a tervezett beiktatas elott be kell jelenteni azt is hogy lesz-e szokomasodperc, es azt is hogy nem(!), ezert ugy elegge fel lehet erre keszulni, meg akkoris ha az NTP epp ne mukodne. Szoval semmivel sem bonyolultabb mint a nyari-teli idoszamitas kezelese. Sot, mivel ez valodi fizikan alapul, nem politikusi-csurhes agybajokon, ezert megjobb a helyzet valojaban :)
Es mire barmelyiket is sikerrel implementaljak, lehet hogy vissza is gyorsulunk ezen a sargolyon annyival hogy mar ki kell szedni egy masodpercet :) Es akkor a php pistikek pofakonyvesek kezdhetik elorol a hisztikejuket ;))
- A hozzászóláshoz be kell jelentkezni
nehogy már megálljunk itt! dobni kéne a szökőnapokat! sőt a szökőéveket is! a 31-ét minden hónapban!
4 és fél éve csak vim-et használok. elsősorban azért, mert még nem jöttem rá, hogy kell kilépni belőle.
- A hozzászóláshoz be kell jelentkezni
Tovább gondolva: Legyen 13 darab 28 napos hónap minden évben, meg néhány (1-2) szökőnap, ami munkaszüneti nap is egyben. Kiszámíthatóbb lenne az élet (ugyanakkora időre, ugyanakkora fizetés), az évszakok meg amúgy sem a naptárhoz kötődnek (lásd nyári/őszi/téli/tavaszi napforduló), hogy a 13. havi fizetésről ne is beszéljünk :).
- A hozzászóláshoz be kell jelentkezni
off: vagy jövőre mindenki kapja meg január 1-én az egész éves fizetését előre, és nézzük meg, ki marad nyárra életben :)
- A hozzászóláshoz be kell jelentkezni
Volt annak idején egy naptárreform-tervezet, eszerint minden negyedév egy 31 napos és két 30 napos hónap lett volna, valamint egy illetve két szökőnap. Mivel a 91 osztható héttel, minden negyedév a hét ugyanazon napjával kezdődne (a szökőnapok a hétnek sem lennének részei). Tehát egy negyedéves naptár minden év minden negyedévére jó lenne.
- A hozzászóláshoz be kell jelentkezni
.... minden negyedév a hét ugyanazon napjával kezdődne
- A hozzászóláshoz be kell jelentkezni
akkor is ha 6 napos egy hét és 30 napos minden hónap (sőt minden hónap ugyanazzal a nappal kezdődne), ráadásul így minden ünnep is mindig ugyanarra a napra esne és egy csapásra bevezetted a 4 napos munkarendet is. a plusz 4/5 napokat meg az év kezdetén márciusban, tavasszal amikor beindul az élet nem nevezed néven alá Asimov évnap.
nincs aláírásom
- A hozzászóláshoz be kell jelentkezni
28 napos hónap
te sem bírsz lejönni arról hogy a hét hét napos kell legyen?
nincs aláírásom
- A hozzászóláshoz be kell jelentkezni
Nekem nyolc, de akkor hívjuk is úgy! :))
Debian - The "What?!" starts not!
http://nyizsa.blogspot.com
- A hozzászóláshoz be kell jelentkezni
Asimov Évszakos Világnaptár:
- A hozzászóláshoz be kell jelentkezni
Tovább gondolva: Legyen 13 darab 28 napos hónap minden évben, meg néhány (1-2) szökőnap, ami munkaszüneti nap is egyben. Kiszámíthatóbb lenne az élet (ugyanakkora időre, ugyanakkora fizetés), az évszakok meg amúgy sem a naptárhoz kötődnek (lásd nyári/őszi/téli/tavaszi napforduló), hogy a 13. havi fizetésről ne is beszéljünk :).
- A hozzászóláshoz be kell jelentkezni
Lehetne 1 év az 10 hónap, és minden hónap 36.525 nap és leszarhatnánk a szökőévet is. Nekem mindegy mikor kezdődik a hónap, nem ragaszkodom a konstans éjfélhez. :)
- A hozzászóláshoz be kell jelentkezni
Nana, ha leszarjuk a szokoeveket akkor inkabb 36.52422 nap legyen egy honap!
- A hozzászóláshoz be kell jelentkezni
Egyszerubb ha mostantol negy napos lesz a munkahet: 1 hetfo, 2 kedd, 3 szerda, 4 csutortok, 5 hetfo, 6 kedd , 7 szerda, 8 csutortok ...
- A hozzászóláshoz be kell jelentkezni
Egyéb megfontalandó javaslataim:
- ne legyen DST
- ne legyen TZ
- a 60-as váltószám helyett használjunk 100-ast
- vagy ne is legyen időszámítás?
- A hozzászóláshoz be kell jelentkezni
Es legyen a π az 3!
- A hozzászóláshoz be kell jelentkezni
Miert, most nem annyi? :-)
- A hozzászóláshoz be kell jelentkezni
Inkább maradjon a 60-as váltószám....
- A hozzászóláshoz be kell jelentkezni
> ne legyen TZ
Ezzel egyetértek, nyugodtan lehetne mindenütt UTC. A napi rutin sehol nem változna, épp csak az órák mutatnának mást, mint eddig.
Debian - The "What?!" starts not!
http://nyizsa.blogspot.com
- A hozzászóláshoz be kell jelentkezni
Ezzel az a probléma, hogy semmivel nem teszi könnyebbé a nemzetközi koordinációt. Ugyanis az emberek a Nap járása szerint élnek, ebben gondolkodnak. Ha mondjuk egy svájci cég vietnámi irodájában dolgozó ember szeretne megbeszélést tartani a svájciakkal, akkor ugyanúgy megy a sakkozás, hogy hány órakor is legyen, hogy mindkettőjüknek beleessen a munkanapba.
Ugyanúgy nyilván kell tartani, hogy melyik országban melyik UTC időintervallum a nap melyik szakát jelenti (mikor van munkanap, tőzsdezárás, mikor kezdődik az új nap a naptárban, stb)
Azaz ugyanúgy létezne időzóna valójában.
- A hozzászóláshoz be kell jelentkezni
Volt erről egy jó írás, kicsit hosszabban fejtette ki ugyanezt vmi pelda mesén át.
- A hozzászóláshoz be kell jelentkezni
Igazából nem is kell nagyon példamese.
Gondolhatjuk úgy, hogy minden ország most is UTC szerint működik, csak éppen nyilvántartjuk, hogy a Nap kb. mikor van a meridiánon (mikor delel). Például nálunk UTC+13-kor delel a Nap, UTC+1-kor van az éjszaka közepe. Stb.
A NASDAQ például UTC+12.30-kor nyit. De nyilvántartjuk, hogy ekkor kb. milyen napszak van ott (helyi idő szerint 9:30).
Ha mindenhol UTC-ben számolnánk, akkor is tudnunk kéne, hogy az milyen napszakot jelöl.
Például ha elrepülök Thaiföldre, UTC+10:30-kor indulok, az út 33 óra átszállással, azaz UTC+19:30-kor landolok a következő napon..na de tudnom kéne, hogy ekkor milyen napszak van? Ébren vannak még az emberek? Nyitva van még/már bármi? Érdemes nekem az UTC+10:30-cas járattal mennem egyáltalán, nem lenne jobb az UTC+15:30-as?
Ja, hogy helyi idő szerint UTC+19:30-kor 07:30 van, ekkor mindent tudok viszonyítani, tudom, hogy milyen életritmus van éppen.
Azaz ha mindenhol UTC lenne a helyi idő, akkor is kellenének a nemzetközi kapcsolatokban hatalmas táblázatok, hogy tudjuk, hogy az éppen a Nap járásának megfelelő életritmusban mit jelent.
- A hozzászóláshoz be kell jelentkezni
Tényleg nen kell, de ettől még jopofa volt, linkelni faja, akkor nem kell neked leirni csak nem segített a google
- A hozzászóláshoz be kell jelentkezni
Nyilván valahogy workaroundolni kell azt a jelenséget, hogy ilyen módon mozog ez a golyó, amin élünk, értem is a példákat.
De nem egyszerűbb-e ránézni az órára bárhol a világon, ami épp 12:20-at mutat, és tudni, hogy 10 perc múlva nyit a NASDAQ? Anélkül, hogy számítgatni kellene, hogy 9:30, melyik időzónában is van? Akkor ennyi óra az eltérés, hozzáadom, az helyiben annyi.
A második példa kicsit emberközelibb, de ha mondjuk étterembe akarsz menni, miután megérkeztél, és látod, hogy opening hours 05:00 - 13:00, akkor is tudni fogod, hogy inkább a közértben kell venned valamit, ha enni szeretnél.
Nem kötekedni akarok, ismétlem, kell a workaround, nyilván egyszerűbb tovább használni azt a rendszert, ami most van, mint váltani, de ha váltanánk, szerintem hamar hozzászokna mindenki.
Debian - The "What?!" starts not!
http://nyizsa.blogspot.com
- A hozzászóláshoz be kell jelentkezni
Tehát ha elmegyek valahova, akkor lookupolnom kell ugyanúgy, hogy "várj, akkor itt melyik időintervallumban vannak nyitva a boltok?". Ami otthon 09-17, az itt most 22-06? Stb.
Ugyanúgy nyilván kell tartani, hogy mikor van nappal és éjjel. Ezt ma úgy oldjuk meg, hogy mindenki helyi ideje szerint közel ugyanakkor van nappal/éjjel. Szerinted miért lenne jobb az, hogy a helyi idők nem összehasonlíthatók, cserébe mindig nyilván kell tartani ugyanúgy, hogy "hm, UTC 18 van. Fel lehet hívni most Jürgent, vagy alszik?"
Ugyanarról a dologról van szó, semmit nem nyerél, cserébe minden kultúra állhatna át arra, hogy mikor van nála nappal és éjjel, ahelyett, hogy kulturálisan igaz lenne, hogy helyi idő szerint mikor van nappal és éjjel.
Ja és akkor már szerintem amúgy Kína diktáljon, az UTC kezdőpontja ott legyen. Hiszen ott sokkal több ember él. Érdemes megnézni, hogy melyik időzónában él a legtöbb ember.
https://blog.cyberclip.com/world-population-by-time-zone
Ennek kéne a standardnek lennie és kész.
- A hozzászóláshoz be kell jelentkezni
> Tehát ha elmegyek valahova, akkor lookupolnom kell ugyanúgy, hogy "várj, akkor itt melyik időintervallumban vannak nyitva a boltok?"
Most is ezt csinálja a legtöbb ember. :))
> Ugyanarról a dologról van szó, semmit nem nyerél...
Ezt mondtam én is, a jelenséget valahogy kezelni kell, de azért a tőzsdés példa esetében szerintem egyértelműen egyszerűbb lenne UTC-ben számolni világszerte. Más esetben nem biztos, de ahogy a jelenlegi rendszert is megszokták az emberek, azt is megszoknák.
Debian - The "What?!" starts not!
http://nyizsa.blogspot.com
- A hozzászóláshoz be kell jelentkezni
Az emberek elsősorban a lokális környezetükben élnek. A többségnek sokkal fontosabb, hogy mikor magas az UV-sugárzás, amikor nem kellene napra menni, mikor megyünk ebédelni, hánykor van vége a munkaidőnek, mint az, hogy mikor nyit a NASDAQ. Nehogy már a világot szétcsesző globalista közgazdász csürhéhez igazodjon mindenki, mert annak a néhány gyökérnek így kényelmesebb.
tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE
- A hozzászóláshoz be kell jelentkezni
> A többségnek sokkal fontosabb, hogy mikor magas az UV-sugárzás, amikor nem kellene napra menni, mikor megyünk ebédelni...
Igazad van, de ezekhez nem is kell ránézni az órára. Pont ez a lényeg, hogy mindenkinek megmaradna a jelenlegi életritmusa, csak az órán lennének más számok. A munkaidő vége meg egy megállapodás, ott is mindegy, hogy 16:00-t vagy épp 03:00-t mutat az óra, ha amúgy a napnak ugyanabban a szakában ér véget a munka.
Debian - The "What?!" starts not!
http://nyizsa.blogspot.com
- A hozzászóláshoz be kell jelentkezni
Értem kezdettől fogva, mit beszélsz, de az igen vacak volna, ha nem mindenütt 12:00-kor lenne dél. Már a cikkek átvétele sem menne. Mondjuk egy amerikai életmód magazinból átvesszük, hogy 11:00-től 15:00-ig ne menj napra, mert bőrrákod lehet, azt számolja át az újságíró, netán az olvasó? Mi emberek, ha tehetjük, éjszaka, sötétben alszunk, nappal dolgozunk, este pihenünk, szórakozunk, tehát a Nap helyzete szinkronizálja az életünket, ezért kell a local time lokális, Nap fázishoz igazított bázissal.
tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE
- A hozzászóláshoz be kell jelentkezni
Én is értem, mit beszélsz!
> Mi emberek, ha tehetjük, éjszaka, sötétben alszunk, nappal dolgozunk, este pihenünk, szórakozunk, tehát a Nap helyzete szinkronizálja az életünket...
Pontosan ezért teljesen mindegy, hogy éppen melyik számra mutat a mutató. :))
Debian - The "What?!" starts not!
http://nyizsa.blogspot.com
- A hozzászóláshoz be kell jelentkezni
Ugyanarról a dologról van szó, semmit nem nyerél, cserébe minden kultúra állhatna át arra, hogy mikor van nála nappal és éjjel, ahelyett, hogy kulturálisan igaz lenne, hogy helyi idő szerint mikor van nappal és éjjel.
- A hozzászóláshoz be kell jelentkezni
Ahogy a helyi idő is egy megállapodás, bármilyen más idő is az lenne. Az időzónákon átívelő tevékenységek egyértelműen profitálnának a dologból. Átállni természetesen nehéz lenne, nyilván nem is érné meg a hercehurcát, ti viszont nem tudtok kiszakadni az UTC+1 / UTC+2-ből. :))
Debian - The "What?!" starts not!
http://nyizsa.blogspot.com
- A hozzászóláshoz be kell jelentkezni
A helyi idő olyan megállapodás, ami hordozható. 12 órakor delel a nap. Nem csak szimpla megállapodás, hanem hordozható dolog.
Hasonló példa: mindenhol éjfélkor kezdődik a nap. Ezután nálad tudni kéne, hogy mikor kezdődik a nap és nyilvántartani, hogy mikor is van új nap.
- A hozzászóláshoz be kell jelentkezni
Igen, ez olyan, mint kódban a relatív ugrás. Akkor bárhova betöldheted, futni fog. Vagy a relatív path. Szintén bármilyen elérési útról megy.
tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE
- A hozzászóláshoz be kell jelentkezni
Vagy a relatív path. Szintén bármilyen elérési útról megy.
nem, az az abszolút.
nincs aláírásom
- A hozzászóláshoz be kell jelentkezni
Úgy értem, ha van egy projected, bárhova teheted, ha relatív a hivatkozás benne. A bázis a '.'.
tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE
- A hozzászóláshoz be kell jelentkezni
Nem érted az idezetet
- A hozzászóláshoz be kell jelentkezni
Továbbá azok most is profitálnak, egyszerűen nem localtime tartják nyilván
- A hozzászóláshoz be kell jelentkezni
"ha nem mindenütt 12:00-kor lenne dél."
szinte sehol sincs 12:00 kor del.
Ma magyarorszag hany negyzetmeteren volt del amikor "magyar ido" szerint del volt (30 sec pontossaggal)?
Hany szazaleka ez az orszag teruletenek ?
Amit nem lehet megirni assemblyben, azt nem lehet megirni.
- A hozzászóláshoz be kell jelentkezni
Beugratós kérdés? 0, mert 13:00 körül delel a Nap.
Ennyit arról, hogy "nehogy már valaki szabályozza, hogy mennyit mutasson az óra, nekem pontosan délben kell ebédelnem!" :))))
Debian - The "What?!" starts not!
http://nyizsa.blogspot.com
- A hozzászóláshoz be kell jelentkezni
Mármint a nyári időszámításban. A normális idő szerint elég közel van délhez, februárban Budapesten pl. 11:57.
- A hozzászóláshoz be kell jelentkezni
Pontosan. Mivel a kérdés a mai napra vonatkozott, ezért gondoltam, hogy beugratós.
Debian - The "What?!" starts not!
http://nyizsa.blogspot.com
- A hozzászóláshoz be kell jelentkezni
Akkik szerint 11:57 eleg kozel van 12:00 hoz, azoknak nem kene masodpercekrol beszelniuk. ;-)
Amit nem lehet megirni assemblyben, azt nem lehet megirni.
- A hozzászóláshoz be kell jelentkezni
mert annak a néhány gyökérnek így kényelmesebb
Mi a frászkarikától lenne kényelmesebb, ha csak UTC lenne?
- A hozzászóláshoz be kell jelentkezni
Nem lennenk felre ertesek, ha ez ember nem ir idozanat .
Amit nem lehet megirni assemblyben, azt nem lehet megirni.
- A hozzászóláshoz be kell jelentkezni
mm/dd/yy kedveli ezt
- A hozzászóláshoz be kell jelentkezni
Ez igaz, de mi köze az időzónához?
Ja, és UTC-ben nem lenne szükség dátumválasztó vonalra se. Igaz, ezzel néhányak szilveszteri bulija agyon lenne csapva. :))
Debian - The "What?!" starts not!
http://nyizsa.blogspot.com
- A hozzászóláshoz be kell jelentkezni
Tehát mindenki számára a nap random váltana, valakinél mondjuk a nap járása szerint délelőtt egyik nap után jönne akövetkező, valahol meg éjjel stb.
Például felkelsz reggel, elmész dolgozol egy órát, majd hazamész, mert ez volt az utolsó munkanapod és vége a napnak?
Az emberi életritmus, amit a Nap járása határoz meg, sokkal ésszerűbben csinálja ezt. Helyi idő szerint élünk, viselkedünk, eszerint számoljuk a napokat is.
- A hozzászóláshoz be kell jelentkezni
Ahhoz van köze, hogy attól még, hogy nem kell kiírni az időzónát, nem lesz rögtön minden egyértelmű :)
- A hozzászóláshoz be kell jelentkezni
Az csak egy szerializációs formátum, semmi köze az időszámításhoz.
- A hozzászóláshoz be kell jelentkezni
Tudom, a félreértésre reflektáltam.
De egyébként az időzóna és a konvenció szerint helyi időzónát jelentő helyi idő is csak szerializációs formátum :-)
- A hozzászóláshoz be kell jelentkezni
Ha komolyan gondoljak, akkor vegyek fel a balerina cipot, es hajra: https://xkcd.com/162/
- A hozzászóláshoz be kell jelentkezni
Oka van, hogy létezik szökőmásodperc. Nekünk IT-soknak feladatunk megoldani, hogy ezt jól kezeljük.
Jól tudjuk kezelni azt is, hogy eltérő időzónák vannak, azt is, hogy vannak szökőévek, akkor ezt is meg kell tudnunk oldani.
- A hozzászóláshoz be kell jelentkezni
En a Meta mernokeit dobnam. Talan nem szennyeznek tovabb a foldet a Facebook, az Instagram es a tobbi, "tobb problemat okozo, mint amennyi hasznot hajt" technologiakkal.
- A hozzászóláshoz be kell jelentkezni
Nem lehet 2xPlusz1-ezni, sajna...
Báár néhány ezret is nyomnék erre....
- A hozzászóláshoz be kell jelentkezni
Ha nem tudnak az olcsó indiai mérnökök megbírkózni a kihívással, akkor nem biztos, hogy a kihívás megszüntetése az üdvözítő megoldás. ;-)
disclaimer: ha valamit beidéztem és alá írtam valamit, akkor a válaszom a beidézett szövegre vonatkozik és nem mindenféle más, random dolgokra.
- A hozzászóláshoz be kell jelentkezni
Nehogy veszelybe keruljon a Metaverzum tervezett release date-je es esetleg halasztva legyen az emberiseg vegleges tonkretetele. :)
- A hozzászóláshoz be kell jelentkezni
Szerintem toroljunk minden hetfo es pentek kozotti napot, tartsuk meg csak a szombat,vasarnapot .
- A hozzászóláshoz be kell jelentkezni
and we believe
As engineers [...] we believe
Case dismissed! =)
- A hozzászóláshoz be kell jelentkezni
Válasszuk két vagy három felé.
Egyik az abszolút idő mérése. Ez UTC-ben történik, nincsenek benne szökőmásodpercek, nincs mit megoldani. 1970 jan. 1. óta ketyeg folyamatosan. Ebben kell minden adatot nyilvántartani, időbélyegezni.
A második, hogy ezt hogyan jelenítjük meg a user számára. Na abban viszont azért nem olyan nehéz kezelni a szökőmásodperceket, időzónákat, stb.
A +1 eset, hogy ha már más égitesteken is jelen leszünk, akkor érvényes-e a földi idő? Hiszen pl. egy marsi UTC nem járhat azonosan a földivel, legalábbis vagy a másodperc hossza nem fog egyezni, vagy az idő nem fog egyezni.
- A hozzászóláshoz be kell jelentkezni
Nincs igazad. UTC-ben van szökőmásodperc, téli/nyári időszámítás nincs benne. Amivel kevered, az az UT/TAI.
A lényeg, hogy van a TAI, ez egyenletes ütemben számolja egymás után az SI másodperceket, és csak azt, fogalma nincs olyan dolgokról, mint perc, meg óra meg nap, meg év. Atomórák mérik. Ezt lehet mondani abszolút időnek, de ez nem tud másodpercnél magasabb egységekről. Azért nem, mert azoknak nem az SI-hez, meg a fény sebességének abszolútságához van köze, hanem a Föld forgásához.
Van az UT, ami a Föld forgása alapján az emberi (biológiai) ritmust is méri, a napokat. Ehhez igazítja az órákat, perceket, másodperceket. Ezzel az a baj, hogy baromira nem egyenletes, egy nap nem 86400 SI másodpercből áll csillagászatilag mérve (sőt, két egymást követő nap nem ugyanannyi ideig tart), mert sajnos a Föld olyan, amilyen. Ezért van az, hogy van olyan perc, ami nem 60 másodpercből áll, ez a szinkronizációs pont a Föld forgásán alapuló "természetes" időmérés, és az SI másodperceket mérő atomórák között.
Az UT és a TAI vegyítése az UTC - SI másodpercekben mérünk a TAI üteme szerint, de mérünk perceket, órákat, napokat is. Azért, hogy ne legyen nagy eltérés az UT által mért idővel, szökőmásodperceket iktatunk be, ezzel ellensúlyozzuk a Föld forgását.
És ugye akkor még nem beszéltünk a naptárrendszerekről, amelyek szökőnapokkal próbálják meg azt a tényt ellensúlyozni, hogy a Föld nem egész számú forgást tesz meg az alatt, amíg megtesz egy kerintgést a Nap körül. Mi meg szeretnénk, ha a jól megszokott évszakok kb. ugyanakkor kezdődjenek, és ne augusztusban legyen tél.
- A hozzászóláshoz be kell jelentkezni
Hmm... akkor többszörös tévedésben voltam, köszi a pontosítást! Szóval először is a unix time-ot kevertem a UTC-vel... de a leírásból szerintem egyértelmű hogy mire gondoltam.
A másik, hogy ezek szerint a unix time-ban is vannak szökőmásodpercek.. na ez a fő probléma, így már jobban értem a helyzetet.
Szóval a lényeg hogy az időt nyilvántartani egy lineáris másodperc időbélyegben kell(ene), és onnan kell a konverziós függvényeket jól megírni az olvasható, időszámítás-függő formátumokra. De így legalább minden időbélyeg egyedi és folytonos.
- A hozzászóláshoz be kell jelentkezni
Amire gondolsz, az a TAI, az mindig egyenletesen számol előre, semmi diszkontinuitás. A konverziós függvények pedig ezt UTC-vé alakítják (jelenleg 37 másodperc az eltérés a TAI és az UTC között). Ebben a konverzióban van diszkontinuitás, mert a Föld forgása nem egyenletes. Mi emberek az UTC-hez szoktunk hozzá. Pont azért, mert a Föld forgásához igazítjuk az életünket és nem az atomórákhoz.
- A hozzászóláshoz be kell jelentkezni
A holdon egyszeru az ido, aki olvasott Szitiusz kapitanyt az vagja, hogy Sol es Nox van, egyenkent 354 orabol allnak, es kesz. :-)
- A hozzászóláshoz be kell jelentkezni
A UNIX időben a +1s nem okoz semmilyen zökkenőt? Mi lesz ha véletlenül (kedvező v kedvezőtlen "csillagállás") -1s lesz az hogyan lenne kezelve?
- A hozzászóláshoz be kell jelentkezni
A POSIX szabvány ezt írja elő:
https://pubs.opengroup.org/onlinepubs/9699919799/xrat/V4_xbd_chap04.htm…
Coordinated Universal Time (UTC) includes leap seconds. However, in POSIX time (seconds since the Epoch), leap seconds are ignored (not applied) to provide an easy and compatible method of computing time differences. Broken-down POSIX time is therefore not necessarily UTC, despite its appearance.
Unix időben nincs szökőmásodperc, cserébe folyamatosan nyilván kell tartani, hogy mekkora az offset a POSIX time és az UTC között.
A POSIX időnek több köze van a TAI-hoz, mint az UTC-hez.
- A hozzászóláshoz be kell jelentkezni
Az előzők miatt ennek utánanéztem, és a wikipédia épp az ellenkezőjét írja (https://en.wikipedia.org/wiki/Unix_time):
Unix time is nonlinear with a leap second having the same Unix time as the second before it (or after it, implementation dependent), so that every day is treated as if it contains exactly 86400 seconds
Vagy megint én értek félre valamit...
- A hozzászóláshoz be kell jelentkezni
Azt érted félre, hogy az a baj, hogy a Unix time szerint egy nap mindenképpen 86400 időegységből áll (Unix másodpercből) áll. Azaz egy adott nap Unix idejéhez (ami csak egy szám) ha hozzáadok 86400-at, akkor a következő nap azonos időpontját kéne kapnom.
Viszont a civil időszámítás (az UTC) nem így múködik, egy nap állhat akár 86399 és 86401 SI másodpercből (ejnye, a Föld forgása ilyen).
Ezért a Unix időt szinkronizálni kell az UTC-hez ilyen esetekben, hogy igaz legyen az, hogy egy nap 86400 Unix másodpercből áll.
Ezt úgy teszik meg, hogy a Unix óra nem jár egyenletesen (ez a nemlinearitás), hanem lassabban/gyorsabban jár, amikor szökőmásodperc van. Facebookéknál például 17 óra alatt nem 17*3600, hanem 17*3600 + 1 SI másodpercet tesz meg a Unix idő (miközben 17*3600 Unix másodperc telik el a számlálón), amikor +1 UTC szökőmásodperc van. Azaz ilyenkor egy Unix másodperc nem egyenlő egy SI másodperccel.
A probléma abból ered, hogy Unix időben minden nap 86400 Unix másodperc hosszú. Miközben a civil időszámításban egy nap 86399-86401 SI másodperc hosszú lehet.
Az SI másodperc hossza mindig jól definiált, az nem változik soha, két SI másodperc mindig ugyanannyi időtartam, emiatt kell szökőmásodperccel szinkronizálni a napok (civil időszámítás) és az SI másodpercek (technikai, fizikai időszámítás) között.
Viszont a Unix másodperc hossza nem definiált (a nap hossza van definiálva 86400 másodpercként), ők a szökőmásodperceket valójában azzal oldják meg, hogy két Unix másodperc eltérő hosszúságú is lehet, ők ezzel szinkronizálnak a napok (civil időszámítás) és a Unix másodpercek (technikai időszámítás) között.
Így talán érthető a probléma jellege: két SI másodperc mindig ugyanolyan hosszú, de két Unix másodperc nem.
A félreértéseket mindig az okozza, hogy nem mindegy, hogy SI vagy Unix másodpercről van szó, csak simán a másodperc fogalma Unix környezetben nem jól definiált.
A Facebook hozzáállása az, hogy a Unix megoldása jobb, és a UTC megoldása a rosszabb. Csakhogy nem számolnak azzal, hogy a valódi, civil életben évezredek óta szeretünk a Föld forgásához igazítani az időszámításunkon. Én amondó vagyok, hogy a Unix-féle specifikáció a rossz, a civil/fizikai/csillagászati időszámítást figyelembe vevő UTC a jobb.
Szerk: ami a fő probléma, hogy a számítógépeken csak konfiguráció kérdése, hogy az óra lassítása/gyorsítása mennyi ideig tart (mennyi ideig oszlatják szét a szökőmásodpercet), meg hogy mikor kezdődik, az rendszerbeállítás-függő. Emiatt két eltérő rendszerből származó, UNIX időszámításon alapuló timestamp, ha eltérő, még jelentheti ugyanazt az időpillanatot, illetve attól, hogy ugyanaz, még jelenthet eltérő időpillanatot, két rendszer Unix szerint mért ideje nem összehasonlítható addig, amíg a rendszereken folyik a smearing. Emiatt az olyan elosztott rendszerek, mint a Facebook, hibákba futhatnak, ha Unix időszámítás alapú timestampeket használnak.
- A hozzászóláshoz be kell jelentkezni
Tökéletesen értem a problémát, csak azt nem értem hogy a Unix time-ot miért így alkották meg. Mert szerintem az lett volna a cél, hogy két Unix time közti különbség mindig abszolút időkülönbséget adjon.
Na de sebaj, úgyis lassan itt van 2038, épp ideje lenne megreformálni. Akkor át lehetne térni a TAI-ra.
Ettől még persze a date() meg ahol megjelenítjük a dátumot és az időt az továbbra is mehet "emberi" időben, időzóna függvényében, szökőmásodercekkel. Viszont ami fontos, hogy a TAI lineáris és egyértelműen leképezhető a lebontott dátum/idő formátumra. Két időbélyeg közti azonos különbség mindig ugyanaz az időtartam lenne. Szeritem arra nincs igény, hogy két időbélyeg közti különbségben mindig 86400 mp. legyen egy nap, hiszen a nap hossza a Föld forgásából adódik, ehhez kár kapcsolni az időt.
A visszafele konverzió is egyértelmű egészen addig, amíg nincs negatív szökőmásodperc.
- A hozzászóláshoz be kell jelentkezni
"csak azt nem értem hogy a Unix time-ot miért így alkották meg. "
Amikor a Unix idő létrejött, még nem volt szökőmásodperc, azt 1972-ben vezették csak be. Amikor a Unix időt bevezették, akkor igaz volt, hogy egy nap mindig 86400 másodperc. Akkor az USA-ban még nem volt egységes DST sem, az 1962-es szabályozás szerint minden tagállam maga dönthetett a DST-ről, ma is vannak tagállamok, ahol nincs DST. A Unixot pedig nem szánták globális szerepre, az olyan fogalmak, mint időzóna-kezelés, lokalizáció, internacionalizáció még teljesen ismeretlenek voltak. Azóta meg, így maradt. Hozzá kéne nyúlni, de kompatibilitási okokból nem lehet.
Szerk: a negatív szökőmásodperc is egyértelmű. Nem arról van szó, hogy kétszer ugyanaz a másodperc lenne UTC-ben. Ott arról van szó, hogy lenne invalid reprezentáció (mint ahogy most is van). Azon a napon, amikor negatív szökőmásodperc van, 23:59:58 után egyből 00:00:00 lenne, 23:59:59 nem létező időpontra mutat. Mint ahogy általában a 23:59:60 invalid reprezentáció, de amikor pozitív szökőmásodperc van, akkor 23:59:60 valid. Mindig egyértelműen lehet konvertálni UTC és TAI között, amennyiben pontosan megvan a táblázat a szökőmásodpercekről. Csak vannak olyan időpontok, amelyek ugyan leírhatók, de valójában invalidak UTC-ben. Mint ahogy DST-ben is vannak ilyenek, amikor 01:59:59 után 03:00:00 jön, akkor nincs olyan, hogy 02:00:00.
- A hozzászóláshoz be kell jelentkezni
Erről egy egyetemi matekóra jut eszembe:
- Van egy soros rezgőkörünk, a tekercs induktivitása 2 H (jó, legyen), az ellenállás 2 Ohm (ööhmmm, mondjuk, hogy ez a tekercs soros vesztesége, de oké, legyen), a kondenzátor kapacitása pedig 2 C.
- Tanár úr, az ellenállás meg a tekercs rendben van, de a 2 C kapacitás az nagyon nem életszerű!
- Az lehet, de így nagyon szép eredmény jön ki!
Debian - The "What?!" starts not!
http://nyizsa.blogspot.com
- A hozzászóláshoz be kell jelentkezni
Hányszor megfogadtam, hogy sörözés után nem postolok... :))
Debian - The "What?!" starts not!
http://nyizsa.blogspot.com
- A hozzászóláshoz be kell jelentkezni
Az még semmi, na de ha egyikből kell visszaszámolni a másikba :D
Ez a videó remekűl összefoglalja:
https://www.youtube.com/watch?v=-5wpm-gesOY
- A hozzászóláshoz be kell jelentkezni
Az a baj, hogy ezek az naptár, időzóna, időszámítás, téli-nyári átállítás már sokszor lefutott körnek számítanak, pro-kontra vannak érvek, ebben a műfajban már nem lehet a kereket újra feltalálni, végső soron a politika dönt. A FB még nem olyan hatalmas, hogy ők döntsenek róla.
Azzal kifejezetten nem értek egyet, hogy a mai modern rendszereken gondot okozna a szökőmásodperc. Eleve netről kérdezik le az időt, és az NTP-s implementációk meg nem úgy állítgatják az órát, hogy átugornak másodperceket, hanem az óra lassításával oldják meg, a futó szoftverek ebből semmit nem vesznek észre. Egy jól beállított rendszeren ennek nem kéne gondot okozzon.
“A computer is like air conditioning – it becomes useless when you open Windows.” (Linus Torvalds)
- A hozzászóláshoz be kell jelentkezni
Bár én személy szerint nem ertek egyet, főleg a vegkovetkezretessel, (bonyolult a valóság, dugjuk vissza a fejünk a homokba), de érdemes lenne elolvasnod amit írtak, nyilván ők is tisztában vannak vele, hogy hogyan működik.
- A hozzászóláshoz be kell jelentkezni
"Eleve netről kérdezik le az időt, és az NTP-s implementációk meg nem úgy állítgatják az órát, hogy átugornak másodperceket, hanem az óra lassításával oldják meg, a futó szoftverek ebből semmit nem vesznek észre. Egy jól beállított rendszeren ennek nem kéne gondot okozzon."
Viszont a civil időszámítás nem így működik, az bizony átugrik másodperceket, csak éppen az NTP ezt nem tudja jól kezelni, meg a szoftverek sem. Pont ez a probléma.
Amúgy a "netről" kérdezik le az időt című dolog is azért érdekes a Facebook számára, mert ő az, aki az időt előállítja, amit lekérdeznek. Saját időszerverei vannak, mint ahogy a Googlenek és társainak is. Azt a fajta smearinget, amit csinálnak, a Google is csinálja, le is írják, hogy hogyan, és ők azt szeretnék, ha az lenne a szabvány: https://developers.google.com/time/smear 24 órás lineáris, a szökőmásodpercre centrált smearing.
- A hozzászóláshoz be kell jelentkezni
> 24 órás lineáris, a szökőmásodpercre centrált smearing.
Tehát az év, hónap, nap, óra, perc, másodperc egységek közül csesszük el az egyetlen olyat, ami egyértelműen definiált, hogy a többi mértékegységre vonatkozó tökéletlen absztrakció megmaradhasson?
Debian - The "What?!" starts not!
http://nyizsa.blogspot.com
- A hozzászóláshoz be kell jelentkezni
A Fészbúkos Cukerberg már akkora arcú, hogy a földnek is bevezényel, hogy hogyan forogjon. Biztos nyerne vele 1$-t, ha nem kellene leprogramozniuk a dolgot.
Senkinek nincs köze világod belsejéhez, neked sincs közöd mások életéhez, csak az Irgalom útján van közöd, Istenektől rendelt kötelességed.
- A hozzászóláshoz be kell jelentkezni