Chyba roku 2038 způsobí problémy, počítače dnes totiž stárnou příliš pomalu

Můj názor  |  zobrazit i odpovědi (trvale)  |  řadit od nejstarších Komentáře nyní řadíme od nejnovějších.
Tímto odkazem můžete řazení změnit.
 |  nových názorů: 69

Názory k článku

avatar
21. 03. 2020 12:25

Ono si nemyslím že by po tom za 157 let štěkl pes jako že by mohl nastat problém v tom, pokud je to zavedeno jako standard, který se udrží 157 let, tak to muže byt problém i pokud již nebude na oběžné dráze létat aktuální stav satelitů. Je to pouze přesunutí problému na jinou generaci. Místo aby se vyřešil tak se jen odsunul.

Souhlasím  |  Nesouhlasím  |  Odpovědět
21. 03. 2020 01:48

Tak uz to na svete chodi, zadna vec nefunguje vecne. Kdyz si letos koupite boty, za 5 let uz budou proslapane.

Souhlasím  |  Nesouhlasím  |  Odpovědět
12. 02. 2020 17:39

-1024 týdnů mi opravdu dělá problém, protože GPSBabel (a jiné) umí korekci o max 999 dnů 23 hodin 59 minut a 59 sekund a tady je potřeba 7168 dnů. To mi připomíná, že jsem se chtěl podívat, jestli neni nějaká nová verze, na to by přece mohla býtr předvolba. Zatím na to mám skript v matlabu (to bych spíš čekal na akademickém pracovišti, schválně teď zkouším, ale ten zdá se taky končí rokem 9999, pak to ukazuje modulo 10000 let, ale aspoň to ukazuje jako datum).
U toho GPS je zajímavé, že mám 4 stejné přijímače, ale do roku 1999 se mi propadly (a nyní v roce 2000) jsou jen ty, které v onu dobu neběžely. Jinak funkce je bez chyby, jenom je v čase o 1024 týdnů jinde, odečíst 1024 týdnů je naprostá brnkačka i v excelu, to jen GPSBabel ani Geosetter tak velkou odchylku nezkorigují.

Souhlasím  |  Nesouhlasím  |  Odpovědět
24. 01. 2020 21:28

také pítchoviny...báť sa o niečo 10kY dopredu, kua sú závažnejšie veci čo treba riešiť, aby to dovtedy niekto mohol riešiť!

Souhlasím  |  Nesouhlasím  |  Odpovědět
avatar
23. 01. 2020 10:07

... když je nahradíme současným linuxovým serverem nebo strojem s Windows 10, budou svůj dedikovaný úkol dělat úplně stejně dobře (nebo také úplně špatně)...To nemusí být tak úplně pravda. Třeba dříve na počítačích byly sériové a paralelní porty, teď už je tam nenajdeme a wokna je už taky moc nepodporují. Když jsem ještě pracoval, ve firmě byly nějaké programy ( a asi tam ještě jsou) co komunikovaly s vnějším zařízením skrzevá paralelní nebo sériové porty. Momentálně se to musí řešit nějakými adaptéry z USB a ne s každým to funguje.

Souhlasím  |  Nesouhlasím  |  Odpovědi (2)Zavřít odpovědi  |  Odpovědět
23. 01. 2020 08:28

Nevím jestli chyba roku 10000 trápí Excel, ale mně rozhodně netrápí

Souhlasím  |  Nesouhlasím  |  Odpovědět
23. 01. 2020 00:14

Roku 10 000 se asi nedožiji, jedině že by spadla cena elixíru mládí

Souhlasím  |  Nesouhlasím  |  Odpovědět
22. 01. 2020 22:20

Další hledisko problému je archivace dat resp. systémů kvůli auditům nebo zákonným požadavkům. Čili kdo bude umět po roce 2038 obnovit data z dnešních Unix systémů do čitelné podoby bude machr. A slovem "dnešních" myslím ty už dnes zastaralé kde se s 64 bity nepočítá. Protože už dnes máme data která mají být obnovitelná za 20-25 let.Jo a před Y2038 nás čeká tuším ještě Y2036 kdy má přetéct NTP. Tu bude multi-platformní sranda.Můžeme doufat že to naše děti zvládnou a nechají nám proudit umělou výživu do žil Všem kdo mají snahu odhalovat a opravovat takovéto pastičky předem děkuji.

Souhlasím  |  Nesouhlasím  |  Odpovědět
22. 01. 2020 22:01

Podle článku ta chyba způsobí problémy až někdy v budoucnosti, ale na Twitteru je případ, když už dneska stála ta chyba několik mio.$ jednu firmu, která se zabývá predikcemi vývoje trhu na 20 let dopředu!
Za prvé jim ta jejich aplikace žádnou chybu vůbec nehlásila, ale přestala generovat reporty, což se jim stalo poprvé. A za druhé na to vůbec nemohli přijít... Ještě bude veselo, si myslím.

Souhlasím  |  Nesouhlasím  |  Odpovědět
22. 01. 2020 17:51

Pokud by z nějakého důvodu nešlo tuhle chybu pořešit použitím 64b (např pokud mi z nějakého "black box systému chodí prostě 32bit čas a já to něho nemůžu sahat - typicky třeba nějaké cesiové/rubidiové hodiny v laboratoři nebo něco na ten styl), tak by se to dalo ošetřit kontrolou jestli je například aktuální datum nižší než datum výroby toho systému (třeba rok 2000), tak se uvažuje že počítadlo přeteklo a natvrdo se přičte těch X miliard sekund co odpovídá tomu 32bit číslu co přeteklo. Tím člověk získá nějaké další roky (jestli správně počítám tak 30 (2000-1970).

Souhlasím  |  Nesouhlasím  |  Odpovědi (1)Zavřít odpovědi  |  Odpovědět
22. 01. 2020 17:21

Zvětšit čítač podle mě není řešení, ale jen oddálení problému a jeho přenesení na další generaci, kde to bude muset někdo řešit a nebo z toho zase bude mít bolehlav. Možná v té době už nebudeme používat dnešní počítače, ale budou to třeba nějaké hybridní zařízení založené na quantových počítačích s biologickou složkou (bůh ví co bude), ale problém přetečení tu bude nejspíš stále.
Proč to nevyřešit rovnou teď a systémově? Prostě si zvyknout na to, že přetečení je zcela "normální" věc a tedy systémy na něj rovnou připravit. Například tak, že hodnota 1.1.1970 nebude fixní, ale nastavitelná. Tedy těsně před přetečením čítače (nebo i dříve) se "počátek" nastaví na aktuální datum a čítač se vynuluje a začne počítat od nového počátku například od 1.1.2020
Je mi jasné, že tohle asi nebude to pravé ořechové, ale pro možnou představu by to mohlo stačit.

Souhlasím  |  Nesouhlasím  |  Odpovědi (6)Zavřít odpovědi  |  Odpovědět
22. 01. 2020 17:09

Někdy je ten čížkův humor i vtipný
Nicméně to nebude ani dopoledne ani odpoledne, ale noc, protože tou dobou bude vyhlášené ekologické stanné pravo a bude zakázana spotřeba energie... Lidstvo toho času bud bydle podzemíGPS: Přežil mobil duben 2019, přežil i Listopad 2019, tak asi vydrží na věky

Souhlasím  |  Nesouhlasím  |  Odpovědět
22. 01. 2020 16:25

bububububu
zase samozrejme o nic nejde

Souhlasím  |  Nesouhlasím  |  Odpovědět
avatar
22. 01. 2020 15:46

S tím Excelem je ještě jedna potíž. Pořadové číslo dne Excel sice počítá od 1.1.1900, ale má špatný algoritmus pro určování přestupných let, takže do toho přičítá i neexistující den 29.2.1900. Proto mu číslo dnešního dne 22.1.2020 vychází na 43 852, zatímco v jiných systémech, kde se to počítá podle stejného principu, ale správně, je teprve den 43 851.Zkuste si v Excelu napsat vzoreček "=DATUM(1900;3;1)-1", vyjde vám 29.2.1900. Ta samá funkce v SQL "SELECT DATEADD(d,-1, DATEFROMPARTS(1900, 3,1))" vrací 28.2.1900.Proto pozor při nejrůznějších importech a exportech dat - pokud se datum exportuje jako číslo, nemusí se to do cílového systému nahrát správně.

Souhlasím  |  Nesouhlasím  |  Odpovědi (7)Zavřít odpovědi  |  Odpovědět
avatar
22. 01. 2020 13:02

Take by mohly lide zacit pocitat cas tak, aby zadna takova chyba nastat nemohla. Predefinovat jednotku casu, aby to nebyla 1.000s, ale treba 1.003s, prepocteno na nynejsi jednotky :)

Souhlasím  |  Nesouhlasím  |  Odpovědi (6)Zavřít odpovědi  |  Odpovědět
avatar
22. 01. 2020 12:58

No nevím Intel vydává staré jako nové takže u Intelu stárne rychle než se zdá 😂

Souhlasím  |  Nesouhlasím  |  Odpovědět
22. 01. 2020 12:44

Typický přístup programátorů: svoji práci jsem udělal a o bugy ať se stará další programátor, který to implementuje.
Další programátor: Co bych se s tím dělal, dám tam neošetřenou výjimku, výjimka stejně v praxi nenastane.
.
.
.
O několik dekád později se uživatelům zhroutí systém, na starý, implementační problém v Core. Další programátor se v dobré víře pokusil o aktualizaci a výjimka nastala.

Souhlasím  |  Nesouhlasím  |  Odpovědi (3)Zavřít odpovědi  |  Odpovědět
22. 01. 2020 12:37

Celkom dobrý článok, ďakujem.

Souhlasím  |  Nesouhlasím  |  Odpovědět
22. 01. 2020 12:36

Jako souhlas, až na to stárnutí počítačů. Tohle už dávno vyřešil Apple https://www.zive.cz/clanky/apple-otevrene-pri... :D

Souhlasím  |  Nesouhlasím  |  Odpovědět
avatar
22. 01. 2020 11:48

2038 už tu bude stejně jenom Skynet.

Souhlasím  |  Nesouhlasím  |  Odpovědi (4)Zavřít odpovědi  |  Odpovědět
22. 01. 2020 11:38

On timestamp je většinou proměnná typu time_t a ten je (obvykle) 64bit na 64bit systémech a 32bit na 32bit systémech. Takže někomu to crashne v roce 2038 a někomu až v 292277026596.Edit: Měla být reakce na comment od Lamasutra

Souhlasím  |  Nesouhlasím  |  Odpovědět
22. 01. 2020 11:03

Proto většina dnešních databází používá k ukládání timestampu 64b.
Ale není nad to vyvolávat paniku a nebo senzaci 18 let předem.
Co by jsme jinak dělali.

Souhlasím  |  Nesouhlasím  |  Odpovědět
22. 01. 2020 11:03

Přežil jsem 2000, přežiju i 2038!

Souhlasím  |  Nesouhlasím  |  Odpovědi (14)Zavřít odpovědi  |  Odpovědět
22. 01. 2020 11:00

Proč 10 bitů, to se v tom schovává ještě něco jiného ?
Co takhle postupně unix timestamp hodit na 64 bit ?

Souhlasím  |  Nesouhlasím  |  Odpovědi (1)Zavřít odpovědi  |  Odpovědět
Zasílat názory e-mailem: Zasílat názory Můj názor