Fórum Root.cz
Ostatní => Odkladiště => Téma založeno: PsychoIT 05. 02. 2015, 09:36:20
-
Tento rok přijde na informační systémy kalamita, 30. června 2015, den D, Y2015.
Nastane konec světa, burzy se odpálí, boty na forexu se zblázní a způsobí hyperinflaci, nastane panika, chaos a zmar.
Konec světa zvěstuje magické číslo 86401, třeste se!
Jinak řečeno opět přijde den který bude mít o sekundu navíc, tzv. přestupnou sekundu. Normální den má 86400 sekund. Někdo mi podobný příspěvek už smazal jako hovadinu, nevzdělanec, takže aby se to nestalo tak to nadhazuji téma a ptám se, jestli vaše projekty jsou na tuto veselou událost připraveny. V reálu snad nanejvýš budou havarovat automaty na kávu a podobně...
-
Copa přestupná sekunda, ale Year 2038 problem (https://en.wikipedia.org/wiki/Year_2038_problem) bude zajímavej :-)
-
Nestane se vůbec nic, drtivá většina zařízení existenci přestupné sekundy ignoruje a ty které ji podporují již mají bugy odstraněny, protože přestupná sekunda nastává zhruba 2x-5x za 10 let.
-
Z tohohle portálu se fakt stala děsná žumpa. Jestli to souvisí se zlidověním IT během posledních 20 let, nebo co… Takovým jalovým blábolením snad dříve technici nezabíjeli čas.
-
Tak na y2k se taky slusny mnoztvi lidi slusne napakovalo, prodavaly se vsemozny analyzatory a za desitky a stovky tisic Kc se analyzovalo ...
Takze cim vetsi brajgl po netu, tim lip, ofce zacnou becet, a ja se rad pripojim k tem, co se na nich napakuji. Idealni kdyby vysel nejakej katastrofickej clanek v HN, to cte hromada managoru a berou to za fakt.
-
Ono kdyby se Y2K neresil, tak to bude slusny pruser.... (samozrejme ne takovy pruser, jako se snazily sugerovat novinove clanky "v X je pocitac, vsechny pocitace se vypnou, X se rozbije")
Nastesti zapracovalo Adamsovo pravidlo pomaych pruseru.
-
Tak na y2k se taky slusny mnoztvi lidi slusne napakovalo, prodavaly se vsemozny analyzatory a za desitky a stovky tisic Kc se analyzovalo ...
Takze cim vetsi brajgl po netu, tim lip, ofce zacnou becet, a ja se rad pripojim k tem, co se na nich napakuji. Idealni kdyby vysel nejakej katastrofickej clanek v HN, to cte hromada managoru a berou to za fakt.
;D ;D ;D
-
Copak sekunda, ale taková nanosekunda..
-
Ono kdyby se Y2K neresil, tak to bude slusny pruser.... (samozrejme ne takovy pruser, jako se snazily sugerovat novinove clanky "v X je pocitac, vsechny pocitace se vypnou, X se rozbije")
Nastesti zapracovalo Adamsovo pravidlo pomaych pruseru.
Presne, ono mimochodem docela zajimavy (a pruserovy) byl i problem roku 2010, viz napriklad: http://jetset.blog.root.cz/files/2010/01/custom-display.jpg
O co slo? No tento vyrobce registracnich pokladen pouzival (rozumne) cip s hodinami realneho casu, ale v roce 2010 se projevil problem s prevodem binary <-> BCD. Takze po roce 2009 to poskocilo na 2016 a co ted s tim? No pruserova vecicka :)
-
pokud si pamatuji dobre na posledni "sekundovy preslap" (2012), problem byl snad jen s javou/tomcatem - jinak to bylo OK
-
A kdyz se mnou souhlasi Pavel Tisnovsky, tak mam urcite pravdu :-D
-
Presne, ono mimochodem docela zajimavy (a pruserovy) byl i problem roku 2010, viz napriklad:
2010 postihlo jenom ty kteří si nedokázali přečíst dokumentaci, nešlo o systémový problém.
Přibližně místo ((year >> 4) & 0xF)*10+(year & 0xF)+2000 napsali year + 2000
-
A kdyz se mnou souhlasi Pavel Tisnovsky, tak mam urcite pravdu :-D
Tak nepochybne :D
-
Presne, ono mimochodem docela zajimavy (a pruserovy) byl i problem roku 2010, viz napriklad:
2010 postihlo jenom ty kteří si nedokázali přečíst dokumentaci, nešlo o systémový problém.
Přibližně místo ((year >> 4) & 0xF)*10+(year & 0xF)+2000 napsali year + 2000
To je presne ted duvod, proc jsem o tom problemu psal. My v IT to vidime jako minor bug, vsak co, to opravi jednoradkovy patch a zatim to v realu byl hodne velkej problem, protoze ty firmy pouzivajici registracni pokladny vlastne porusovaly zakon (navic jak to druha strana dostane do ucetnictvi?), opravit to neslo (zpetny zasah do logu registracni pokladny??:) a dost se to resilo.
-
plky
a pro ty druhe
dobre vam tak, pro praci s casem sou tu knihovny
-
plky
a pro ty druhe
dobre vam tak, pro praci s casem sou tu knihovny
presne tak a pokud je nahodou chyba v knihovne, pak budeme nadavat ze mi nic ale za problem muze spatna knihovna....
http://i.stack.imgur.com/jiFfM.jpg
-
presne tak a pokud je nahodou chyba v knihovne, pak budeme nadavat ze mi nic ale za problem muze spatna knihovna....
http://i.stack.imgur.com/jiFfM.jpg
jenomze
- je o dost vetsi sance, ze je to spravne v knihovne nez u mne
- alespon se to bude opravovat na jednom miste
Nevyhoda je
- knihovna muze rozsirit jinak nepravdepodobnou chybu na vic mist
-
pro praci s casem sou tu knihovny
Ani knihovna není žádná záruka, prů*er s přechodem na letní čas zde http://lists.uclibc.org/pipermail/uclibc/2011-October/045827.html
-
plky
a pro ty druhe
dobre vam tak, pro praci s casem sou tu knihovny
presne tak a pokud je nahodou chyba v knihovne, pak budeme nadavat ze mi nic ale za problem muze spatna knihovna....
http://i.stack.imgur.com/jiFfM.jpg
Ano, to je dulezite. Vzdy je potreba mit nekoho, na koho to hodit. :)
-
Hlavne je dulezite nedelat neco, co uz nekdo udelal a nejspis lepe nez ja...
Zajimalo by mne, koho z nas chce zamestnavatel/zakaznik platit za napsani dalsi (nejspis navic blbe odladene) knihovny pro praci s casem, aby ji pouzil v jeho informacnim systemu....
-
pro praci s casem sou tu knihovny
Ani knihovna není žádná záruka, prů*er s přechodem na letní čas zde http://lists.uclibc.org/pipermail/uclibc/2011-October/045827.html
argumentovat tim ze knihovna neni zaruka tak si to udelam sam je logika jak motika
a pro ostatni nejde o to hazet vinu na tvurce knihovny, ale o to ze si stim mozna nekdo dal vic prace nez vy, zvlast pokud se jedna o standartni knihovny, ikdyz ani to neni zaruka, holt software neni letadlo a muzeme si dovolit pady, nebo nemuzem ? nebo spise nemeliby jsme ?
-
nebo spise nemeliby jsme ?
Ne, nemeli bychom. :-)
-
O co vic vadi sekunda navic nez den navic (29. unor)? Vzdyt jde v principu o stejnou vec...
-
Hlavne je dulezite nedelat neco, co uz nekdo udelal a nejspis lepe nez ja...
Zajimalo by mne, koho z nas chce zamestnavatel/zakaznik platit za napsani dalsi (nejspis navic blbe odladene) knihovny pro praci s casem, aby ji pouzil v jeho informacnim systemu....
otazka je co chce zakaznik... pokud zakaznik ocekava funkcni reseni a existujici knihovna je treba totalni sracka napsana dvoma 17tiletymi spratky pak nevim nevim... kdyz se podivate kdo a jak napsal ruzne standardni knihovny tak nekdy si rikam ze i muj 5tilety syn by snad zvladl napsat takovy kus sracek... ono je to samozrejme case by case jine ale rict ze vsechny knihovny jsou proste fajn je nesmysl...
-
Tak samozrejme, funkcnost ma prednost. Ale malo kdy jsem za posledni leta zazil potrebu psat neco mimo vlastni logiku aplikace na kolene.
-
Já to zase zažívám furt. Ale já mám holt trochu specifickou práci... Jako embeďák mám někdy pocit, že knihovny na obsluhu HW dává výrobce psát studentům prvního ročníku řeznickýho učiliště na brigádě >:( a že je pod jejich stavovskou čest to jednou jedinkrát udělat jinak. A je to u všech, od Atmelu po Zilog!!! :(
-
O co vic vadi sekunda navic nez den navic (29. unor)? Vzdyt jde v principu o stejnou vec...
Ta prestupna sekunda je na nizsi urovni. V podstate - ted to hodne zjednodusim - mame unix time, ktery si tika po sekundach uz od roku 1970, ovsem prave pri leap seconds se bud na sekundu zastavi nebo naopak preskoci (takze nektere hodnoty nereprezentuji zadny cas). U data to tak neni, prevod z unix time na datum skutecne resi knihovny, to si (snad :) nikdo sam nepise a navic je dopredu znamej algoritmus. U leap sekund to tak neni.
Co je potencialni problem, ze ani difftime() to nemusi vsude resit spravne.
-
prevod z unix time na datum skutecne resi knihovny, to si (snad :)) nikdo sam nepise a navic je dopredu znamej algoritmus.
I při použití embeded Linuuxu jsem byl nucen napsat si vlastní převod. localtime_r občas zamrzalo - zavolal jsem funkci, ale už jsem se z ní nedostal.
Zkusil jsem v Androidím tabletu nastavit rok 2038 a celý tablet zamrzne. Nereaguje vůbec na nic. Naštěstí se dá hardwarově resetovat a po resetu normálně běží (s datem 2.1.1970)
Android mě s časem celkově štve. Aby šel nastavit čas aplikací, tak se musejí upravovat práva na zápis souboru, který je definovaný v read only oddíle... A když už se povede čas změnit, tak v aplikaci přestanou fungovat časovače.
-
Horší bude, až nastane Y3K..
-
V roce 2000 jsem ani nechápal co se má stát a proč s tím všichni blázní.
V roce 2038 žádná přestupná sekunda hrozit nebude, pochybuju že by to přeci jen ovlivnilo výrobu kamenné sekery nebo kvůli tomu byly problémy s bydlením v jeskyni.
-
O co vic vadi sekunda navic nez den navic (29. unor)? Vzdyt jde v principu o stejnou vec...
Hodne to zjednodusim, ale pokud jste nekdy psal program ktery pracoval casem, psal jste asi neco takoveho, ze?
Nebo jste predpokladal, ze minuta muze mit 61 sekund?
if (sec>=0) and (sec<60) then print "To je OK"; else print "Chyba casu!";
-
V roce 2000 jsem ani nechápal co se má stát a proč s tím všichni blázní.
V roce 2038 žádná přestupná sekunda hrozit nebude, pochybuju že by to přeci jen ovlivnilo výrobu kamenné sekery nebo kvůli tomu byly problémy s bydlením v jeskyni.
Ovšem blbý bude, když bude mít jeskyně elektronický zámek a ten se samovolně otevře, protože vyjde, že je čas menší, než čas přiložení karty + timeout 3000 ms a nebo třeba nedovolí odemknutí, protože ještě neplynul deadtime posledního otevírání (opět je čas menší než čas přiložení karty + timeout).
Taky bude nebezpečné jet výtahem, protože ten vyhodnotí, že jede nesmírně malou rychlostí (nebo naopak velkou) a po měniči bude chtět adekvátní výchylku, tedy zrychlovat, zrychlovat, zrychlovat, až udělá díru do podlahy (nebo naopak zůstane stát a nikdo s ním nehne). Docela blbý je taky to, že ve chvíli chyby výtahu se taky nikam nedovoláte, protože se mobil kompletně zasekne a pokud nepůjde provést HW reset (např vyjmutím baterky), tak ho můžete použít pouze jako nekvalitní pazourek.
...