A Meta mérnökei szabadulnának a szökőmásodpercektől

Címkék

"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.

Hozzászólások

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.

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 ;))

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.

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 :).

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.

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

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 :).

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?

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.

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. 

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

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.

> 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

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 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

É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

É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

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 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. 

"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.

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.

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.

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.

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.

Szerintem toroljunk minden hetfo es pentek kozotti napot, tartsuk meg csak a szombat,vasarnapot .

and we believe

As engineers [...] we believe

Case dismissed! =)

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.

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.

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.

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 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 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.

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...

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.

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.

"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.

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

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)

"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.

> 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

Szerkesztve: 2022. 07. 28., cs – 06:32

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.