Vlákno názorů k článku
Letní čas za to nestojí, řeší se v Evropském parlamentu
od MP - Z hlediska IT - zrusit.
Z hlediska dopravy -...
-
Karel (neregistrovaný)
To moc neřeší. IT není jen o serverech a umělé inteligenci. Značná část IT jsou programy, co slouží lidem. A to problém bývá přesto, že server ví naprosto přesně, kdy se má co spustit nebo kdy začíná který meeting. Obzvláště u pravidelných pondělních konferenčních hovorů se stává, že někdo se marně připojí dřív, nebo až o hodinu později.
A ani tomu moc nepomáhají všelijaké výjimky. Naposledy byla legrace díky tomu, že se změnil šéf. A většina lidí věděla, že má kancelář ve Phoenixu. Ale už málokdo věděl, že v tom státě, kde celý letní den netrpělivě čekají, až nad pouští zavládne noc, letní čas nevedou. Bohužel ani autor jistého SW - ten dovolil zadat jen stát "USA" a pak časové pásmo. Jo jo, Arizona.
-
Froggy (neregistrovaný)
Provozujeme ERP systém - DB je v UTC. Ale co má chudák uživatel dělat, když se zobrazí výrobní cyklus 2:00-2:00 o délce jedna hodina? Nebo 2:59-2:01, co je taky pěkné. Většina GUI prvků samozřejmě nezdůrazňuje, že se jedná o zimní, nebo letní čas. Pak je tady problém, když počítáme něco na dny - dělit to vždy 24 nebo dělat výjimky... atd. A když k tomu přidáme pobočky v Austálii a USA, tak je to mazec ;-)
-
Ondra Satai NekolaZlatý podporovatelNo ona to totiž je primitivní úloha jen pro primitiva. Že zvládneš položit otázku na jednu jednoduchou větu, co jí pochopí prvňák, neznamená, že odpověď musí být jednoduchá nebo vůbec existovat.
A nebo jinak: realita je složitá a jednoduše ji nepopíšeš modelem, kde je rok vždy stejně dlouhý. Ostatně na tvou otázku je odpověď "jak kdy" i bez přestupných sekund, stačí přestupné dny...
-
Ale i do te prestupnosti se aspon nekteri snazi vnest system a zjednodusit v soucasnosti zbytecne slozite planovani v case. Viz https://en.wikipedia.org/wiki/Hanke%E2%80%93Henry_Permanent_Calendar
-
Jenze ani soucasny kalendar neni "alligned" akorat je zbytecne komplikovany. Tento (nebo jiny) novy kalendar
1. usnadni jakekoli planovani a domlouvani v case pro bezne lidi a
2. take definuje presne a jednoduseji predem, kdy bude dochazet k srovnani s "astronomickou realitou" (takze se zase zjednodusuji vypocty, protoze chybu zadefinujeme a zname predem.) a
3. astronomove a ti, kteri ke sve praci potrebuji "astyronomickou realitu" stejne musi svoje vypocty resit nezavisle na soucasnem kalendari.Zkratka mi priojde vyhodnejsi pouzivat jednodussi system, kdyz presne vim o kolik se lisi od skutecnosti, nez system, ktery je slozity (Gregoriansky kalendar) ale i presto nepresny, akorat se ta nepresnost hur vycisluje a hur do systemu zakomponovava.
Proste se v tom tom 16. stoleti sice snazili, ale presnosti stejne nedosahli a tak ma smysl to revidovat aspon tak, aby to bylo jednodusis pro vetsinu beznych uzivatelu. -
Karel (neregistrovaný)
Nejprve definujte rok. Pokud rok definujete jako 365 * 24 * 60 * 60 sekund, pak je to snadné. Pokud do definice zahrnete fakt, že některé roky mají 366 dní, pak už musíte říci kterých deset let máte na mysli. Pokud použijete astronomickou definici "rok je doba, která uběhne mezi dvěma průchody Země stejným místem oběžné dráhy", tak na to se dá odpovědět zpětně také jen pokud řeknete, které roky a konkrétně které místo v prostoru máte na mysli. Spočítat to dopředu také už dneska umíme, byť stále ne moc dobře.
Jinak mi přijde, že váš odpor k přestupným sekundám se dost podobá tomu, co lidé řešili, když se měnila pravidla pro přestupný rok. Shválně se podívejte, jak tehdy ryli do Řehoře, že zavádí takovou kravinu jako je solární kalendář nebo tropický rok. Vždyť koho zajímá kdy je slunovrat nebo rovnodennost, no ne? A správný mořeplavec se bez znalosti polohy taky obejde.
-
Ondra Satai NekolaZlatý podporovatel
Ten ho jenom upravil. Byl soucasti i Julianskeho kalendare, jen jinak rozlozeny.
-
SB (neregistrovaný)
Na přestupné sekundě mi nepřijde nic divného (protože den hold celistvý počet sekund nemá), ale pokud jsem to správně pochopil, tak nějakého pičuse napadlo jí korigovat i unixový čas, místo aby zůstala pouze v konverzi unixový čas <-> kalendář a unixový čas zůstal pevnou časovou vzdáleností od epochy na Zemském povrchu. Zde vidím neomluvitelnou chybu.
-
Z hlediska IT nebo dopravy je to celkem jedno – stejně ti vždycky zůstanou různé časové zóny a musíš s nimi umět počítat (např. vlak nebo letadlo, které je během své trasy překračuje). Letní čas je vlastně jen další časová zóna. Je to už jen celkem malá komplikace navíc – tedy pro IT – pro lidi to je problém daleko větší a kvůli nim by primárně posouvání času nemělo existovat.
-
Petr M (neregistrovaný)
Implmentoval jsi něco low-level s reálným časem? Nějaký ovladač RTC čipu, logování, ukládání do DB...? Ono je to jednoduchý, když to někdo udělá za tebe, ale pokud má ke změně dojít automaticky, tak jenom algoritmus pro změnu zabere 40-60% binárky ovladače, pokud má být univerzální a použitelný všude. Protože jenom kvůli téhle chvostovině musíš mít výpočet, jestli je zrovna druhá sobota v měsíci a podobný nesmysly. Navíc hlídat změny pravidel (globálně) a updatovat pravidla, sotva se diktátor v Tramtárii rozhodně, že se bude posouvat jenom o 25 minut a na druhou stranu.
Lidi jsou samo důležitější, ale i v tomhle ohledu by to ušetřilo tuny práce.
-
A není lepší to řídit zvenku? Stejně ta zařízení bývají propojená nějakou sběrnicí, nejsou většinou úplně autonomní, tak by nebyl problém jim poslat zprávu o tom, že si mají posunout hodiny. Implementovat časové zóny a DST na jednočipu bych nechtěl, ale IMHO to není nutné – tyhle záležitosti může řešit nějaký větší počítač – a jednočip nebo PLC by se věnovaly jen spínání, reakcím v reálném čase atd.
-
Petr M (neregistrovaný)
Chlape, tys to narovnal.
Budu mít dejme tomu billboard někde na výjezdu z města. Osvětlený s tím, že si při výlepu zákazník objedná na tu měsíc dlouhou kampaň svícení řekněme 20:00 - 23:00 a 05:00 - 07:00. Takže to lepiči nastaví na displeji malýho časovýho spínače a je to (otázka pěti minut).
Kvůli tobě, aby to mohlo běžet přechod z jednoho času na druhý, se buďto:
- pošlou lepiči přenastavit čas řekněme na 20 plochách ručně
- ke každýmu hodí ještě nějaký LTE modem, IP stack a implementuje NTP
- budou objednávat kampaně s ohledem na DST a když zákazník chce kampaň, která přesahuje změnu času, tak ho obchodník odpálkujePřitom správný ( = levný, jednoduchý, spolehlivý, bez práce navíc) řešení je ten čas prostě neměnit a jet lineárně od instalace po zboření s tím, že při nastavování lepiči občas zkorigují nepřesnosti. Jenomže to s DST jaksi nelze.
-
Petr M (neregistrovaný)
V embedded světě si o časovým pásmu můžeš nechat leda tak zdát. A víš proč?
- Potřebuješ offset proti UTC pro dva časy. Pokud to bude s krokem 15 minut, rozsah +/-2h, tak to jsou 2x 5b.
- K tomu potřebuješ info, od kdy to platí - měsíc (4b) a den (třeba 3rdFriday - kolem 60 hodnot), to je dalších 7b.
- Takže časový pásmo ti definuje minimálně 32b, pokud názvy budou v tabulce v manuálu a zadáváš jenom číslo. Je fajn to mít dimenzovaný na 256 států (protože USA, Rusko, Čínu,.. nemůžeš brát jako jeden stát s jedním pravidlem a je fajn na to využít těch 8b). Tím jsi na 256*4 = 1kB dat jenom o časových pásmech. A ty data musíš průběžně aktualizovat (= nutnost konektivity). A už máš v systému dva časy (lokální a UTC) a třeba při nastavování musíš mít jistotu, že uživatel ví, který zadává... -
Petr M (neregistrovaný)
Šlo o záznam, který algoritmu řekne, kdy se má na základě kódu státu automaticky přepnout čas. Struktura v RTC pro zpracování má navíc jenom ten jeden bit pro LČ.
Pro offset proti zeměpisné pozici stačí int5. Dá to rozsah -16..+15. S tím, že pokud je krok nastavení offesetu 15 minut (někde je čas o 30 minut mimo, třeba v Indii), je to -3:45 .. +4:00. Je to proto, že některý ujetý ostrovy jsou ujetý o 2h proti pásmovýmu času. Obojí poskytuje rezervu, jak krok 15 min. proti používaným 30 min., tak 4h vs. 2h pro odchylku od normálního pásmovýho času.
A přechody máš dva, takže 3B ti nestačí ani náhodou. Pro komplet informaci o časovým pásmu a dvou přepnutích času potřebuješ min. 91b (fyzicky 12B). Ta redukce na 32b byla nejjednodušší varianta, kdy je časová zón řešena jinde a přepne se o půlnoci.
-
strepty (neregistrovaný)
Ok mame tu vo vlakne dvoch programatorov ktory to asi programovali, tak sa spytam, ako sa Vas kod vyrovna s tym ze zrusia letny cas? Pretoze sa mi zda ze riesite otazku ako keby sme zacinali od nuly, ako by sme sa rozhodovali ci po usadeni na Marse zavedieme alebo nezavedieme letny cas, lenze tu sa bude zacinat s milionmi existujucich programov tu na Zemi.
Neberte moju otazku osobne. pytam sa lebo root je odborny web a je tu sanca ze najaky politik si to precita a bude sa to snazit presadit a z diskusie tu by vyplynulo ze ziaden problem nebude. Je to naozaj tak? -
BobTheBuilderStříbrný podporovatelNo vidíte, v Rusku to vyřešili - železnice používá na celém území moskevský čas. A v Číně začíná škola (nebo ještě nedávno začínala) všude podle pekingského času, to je ještě lepší - někde chodí děti na 6 astronomického času, jinde na 10.
-
BobTheBuilderStříbrný podporovatel
Myslím, že ne. Viděl jsem nějaký video od chlápka, který vyrazil vlakem za polární kruh (poslední část byla po firemní trati Jukosu), a právě to ukazoval tam někde, už mimo magistrálu.
