Nechápu, proč by mělo být kvůli drobné úpravě definice časové zóny potřeba opravovat "miliony jednotlivých programů". Proč by měla triviální úprava (která se navíc v různých zemích světa odehrála už mnohokrát) způsobovat "zmizelé funkce a pohledy na data, které nejdou otevřít"?
By mě zajímalo jak ten začátek letního času definuješ natvrdo. To není jako přechodný rok dělitelný čtyřmi. I velikonoce jsou determinističtější než začátek a konec letního času, jelikož jsou dané astronomickými úkazy (a dlouhodobě neměnnou tradicí), zatímco letní čas je věcí místní vyhlášky.
Vidim to podobne.
Dobre napsane programy si poradi hned co je admin restartuje. A ty spatne napsane proste zacnou fungovat za tri tydny.
Letos probehla leap second a nic vazneho nebylo. Pred nedavnem posouvali zmenu casu v Australii a svet se tocit neprestal.
Problemy byly urcite zpusobeny tim, ze programatori-prasata pocitali ve svych genialnich vytvorech generovanych metodou pokus-omyl s tvrdym zacatkem a koncem letniho casu, misto aby spolehali na system. Dnes totiz programuje prakticky kazdy, kdo umi usnout s hlavou na klavesnici.
Slovni definice rika, ze velikonoce pripadaji na prvni nedeli po prvnim jarnim uplnku. Takze si pockate na prvni jarni den, pak na uplnek a pak na prvni nedeli. A jsou velikonoce.
Vetsina programu predpoklada spojity cas bez mezer a opakovani minulosti... - problem cislo jedna.
Pokud uz program s nejakym DST pocita, je velmi neprakticke a neefektivni proverovat tuto okolnost pri kazde a jakekoli praci s casem. Takze v praxi se to vetsinou dela pri instancovani neceho, co s casem operuje... kupodivu casto se tak deje pouze jednou a to pri inicializaci celeho systemu/programu. Kupodivu je dost systemu, ktere neni mozne jednoduse "restartovat"... (nerikam, ze musi nutne dojit ke skodam, diky redundanci nemusi, ale neni to jednoduchy proces, zejmena pokud redundance predpoklada stejny (synchornni) a spojity cas vsech nodu)
Ja bych z provozniho hlediska opravdu ten prechod nevidel zase tak uplne bezproblemovy... - a IT odbornici ve svetovych firmach casto fakt nejsou troubelini, musi provozovat systemy s 5 a vice devitkami...
PS: Ceho se asi tak tykala zmena tzdata*.rpm, kterou teprve MINULY tyden distribuoval napr. RedHat? Tomu se rika dostatek casu?
Přesně tak. Zkuste si představit poměrně triviální problém elektronické pokladny. Ta vydává lístky s lokálním časem, ale musí si ukládat CET nebo něco takového, aby se to dalo synchonizovat. Navíc při vyhledávání dle lokálního SELC se neví, zda lístek byl vydán v 2h55min starého času nebo nového času, hodnoty se překrývají. Zkrátka je to podivuhodlná nesmyslnost, kdy vlaky stojí hodinu v zastávce :-(
Rozumně napsaný program ukládá časové údaje vázané na lokální čas v lokálním čase a časové údaje vázané na UTC v UTC. Pro převod mezi lokálním časem a UTC používá systémové funkce k tomu určené. Pak změna definice časové zóny znamená opravu jejího definičního souboru a ne opravu "milionů jednotlivých programů".
Ceho se asi tak tykala zmena tzdata*.rpm, kterou teprve MINULY tyden distribuoval napr. RedHat? Tomu se rika dostatek casu?
Nevím jak u Red Hatu, ale v OpenSuSE 10.2 se ta oprava dotkla jediného souboru mimo /usr/share/zoneinfo, a to /usr/sbin/zic; navíc si ani nejsem jistý, že oprava tohoto příkazu opravdu souvisela se změnou definic amerických časových zón a nešlo o nějakou opravu, která se s tím jen svezla (nechce se mi teď porovnávat source RPM). Takže tento příklad svědčí spíš pro můj pohled na věc…
Upozorníme vás na články, které by vám neměly uniknout (maximálně 2x týdně).
