Portál AbcLinuxu, 2. května 2025 00:11
Prý nám na podzim tu hodinu vrátí. To jo. Sedm měsíců na ní budou rajtovat a pak ji jednoho podzimního rána umolousanou, znectěnou a ohmatanou milostivě dostaneme zpět.Cestou z velikonoční vigilie se mě nejstarší syn (10 let) zeptal, proč by bylo obtížné změny času zrušit, když si tolik lidí (v jeho okolí) myslí, že jsou nesmyslné. Chvíli jsem argumentoval, že by se musely na jednom datu dohodnout pokud možno všechny evropské země, protože by to jinak působilo problémy v dopravě, apod. V tom to ale není. Ve Spojených státech amerických posunuli hodinky už před 14 dny, v Brazílii dokonce už před šesti týdny, a to navíc na opačnou stranu. Letové řády se s tím nějak vyrovnaly… U nás letní čas zavedl Hitler. Zrušit by ho dokázal zas leda nějaký diktátor. Při pohledu na Hrad připadá v úvahu třeba Vladimir Putin. Ovšem, na tomhle příkladu je vidět, jak se chová Rus. Myslíte, že tu ukořistěnou hodinu vrátil? Ani nápad! Letní čas teď v Moskvě platí celoročně. (Oprava: Rus nakonec odcizenou hodinu po 3 letech vrátil. Za upozornění děkuji uživateli randy.) Letní čas se neujal ani v Číně. Zavedli ho, šest let to utrpení vydrželi (1986-1991) a pak ho zase zrušili. To by tak určitě udělali, kdyby se to vyplácelo, že. A to se ani nesnažím odhadnout, jak změny času zbytečně komplikují jakýkoli softwarový projekt, který musí pracovat s tzv. reálným časem. Schválně, zkuste se podívat na implementaci knihovní funkce
mktime
a řekněte, jestli ten kód chápete. To
ovšem ještě nic není proti neustálému šťourání do toho, kdy přesně v které zemi ten
posun o hodinu nastane. Kdo má čas a chuť, ať si přečte komentáře v definici
časových zón (pro slabší nátury v
Evropě, pro silnější v
Jižní Americe). Ano, opravdu se v Brazílii to datum jeden rok měnilo na
poslední chvíli jen kvůli volbám; zažili jsme si s tím tehdy v SUSE L3 pěkných pár horkých chvilek. Kolega měl pak ještě dlouho na whiteboardu napsáno: "I hate timezone updates" (asi 20x pod sebou).
Zkrátka letní čas je podle mne jenom pro zlost.
Tiskni
Sdílej:
Schválně, zkuste se podívat na implementaci knihovní funkce mktime a řekněte, jestli ten kód chápeteNe, ale to přikládám absenci srozumitelných komentářů
U nás letní čas zavedl Hitler. Zrušit by ho dokázal zas leda nějaký diktátor.
To je ovšem hodně velká zkratka, viz onen zmíněný zdroják timezone balíčku nebo přepis do lidské řeči na wikipedii:
Letní čas byl znovu zaveden v důsledku úsporných opatření za druhé světové války. V českých zemích (tehdy v Protektorátu Čechy a Morava) fungoval nepřetržitě (!) od 1. dubna 1940 až do 4. října 1942, dále pak v letních měsících let 1943–1949. Na přelomu roku 1946 (1. prosince 1946 – 23. února 1947) byl zaveden také tzv. zimní čas, kdy byl čas posunut o jednu hodinu dozadu – tento opačný posun je zřejmě světovým unikátem.[zdroj?] Příslušné vládní nařízení bylo vydáno 27. listopadu, tedy čtyři dny před změnou.
Každoroční letní čas byl v Československu zaveden v roce 1979. Po několika letech se ustálilo pravidlo, podle kterého se letní čas zaváděl poslední březnový víkend (v noci ze soboty na neděli) a končil poslední zářijový víkend. Od roku 1996 je letní čas o jeden měsíc delší – trvá až do posledního víkendu v říjnu, čímž je letní čas zaveden po větší část roku než čas pásmový. Tato změna byla provedena v celé Evropské unii, takže se jí přizpůsobila i Česká republika.
Pomineme-li různé konspirační teoretiky, všeobecný konsensus je, že v roce 1979 byl Hitler už přes třicet let po smrti. :-)
a v té hodině, která na podzim v lokálním zobrazení neexistujeExistuje, dokonce dvakrát, takže kromě času musíš zobrazovat i timezone, ne?
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.-- http://pubs.opengroup.org/onlinepubs/9699919799/xrat/V4_xbd_chap04.html#tag_21_04_15
Podle wikipedie to nemá žádný vztah k našemu datu, je to prostě jen počet vteřin od 00:00:00 1.1.1970.Ano, jenže to kvůli snazším výpočtům počítá s tím, že každá minuta má právě šedesát vteřin. Nebo-li se to tváří, jako by žádné přestupné sekundy neexistovaly, a když taková sekunda nastane, musí se posunout hodiny.
2016-03-28T20:17:14+0200
na korektní timestamp.
*Doufám, že v tomhle nežiji v omylu.
protože ten se s každou přestupnou sekundou posune, aby převod na aktuální čas seděl.To se mi zdá jako dost divná praktika stavící na hlavu celý smysl timestampu. Přímo v té specifikaci píšou:
The topic of whether seconds since the Epoch should account for leap seconds has been debated on a number of occasions, and each time consensus was reached (with acknowledged dissent each time) that the majority of users are best served by treating all days identically. (That is, the majority of applications were judged to assume a single length-as measured in seconds since the Epoch-for all days. Thus, leap seconds are not applied to seconds since the Epoch.) Those applications which do care about leap seconds can determine how to handle them in whatever way those applications feel is best. This was particularly emphasized because there was disagreement about what the best way of handling leap seconds might be. It is a practical impossibility to mandate that a conforming implementation must have a fixed relationship to any particular official clock (consider isolated systems, or systems performing "reruns" by setting the clock to some arbitrary time).
4.15 Seconds Since the Epoch A value that approximates the number of seconds that have elapsed since the Epoch. A Coordinated Universal Time name (specified in terms of seconds (tm_sec), minutes (tm_min), hours (tm_hour), days since January 1 of the year (tm_yday), and calendar year minus 1900 (tm_year)) is related to a time represented as seconds since the Epoch, according to the expression below. If the year is <1970 or the value is negative, the relationship is undefined. If the year is >=1970 and the value is non-negative, the value is related to a Coordinated Universal Time name according to the C-language expression, where tm_sec, tm_min, tm_hour, tm_yday, and tm_year are all integer types: tm_sec + tm_min*60 + tm_hour*3600 + tm_yday*86400 + (tm_year-70)*31536000 + ((tm_year-69)/4)*86400 - ((tm_year-1)/100)*86400 + ((tm_year+299)/400)*86400 The relationship between the actual time of day and the current value for seconds since the Epoch is unspecified. How any changes to the value of seconds since the Epoch are made to align to a desired relationship with the current actual time is implementation-defined. As represented in seconds since the Epoch, each and every day shall be accounted for by exactly 86400 seconds.Tedy je to pocet sekund od epochy, ale bez zapocitani prestupnych sekund. Tedy mensi udaj, nez skutecny pocet sekund od epochy (vzhledem k tomu, ze od epochy probehlo nekolik 'kladnych' prestupnych sekund, ktere nebyly zapocitany).
Tedy je to pocet sekund od epochy, ale bez zapocitani prestupnych sekund. Tedy mensi udaj, nez skutecny pocet sekund od epochy (vzhledem k tomu, ze od epochy probehlo nekolik 'kladnych' prestupnych sekund, ktere nebyly zapocitany).Ano, takhle jsem si to myslel. Pokud to dobře chápu, tak Filip Jirsák tvrdí*, že se ten čas posouvá o přestupné sekundy, tedy že timestamp není menší, než skutečný počet sekund od epochy, protože epocha byla posunuta o 26 vteřin. *Viz:
protože ten se s každou přestupnou sekundou posune, aby převod na aktuální čas sedělRád bych se definitvně dobral toho, jak to tedy je, protože to používám všude možně.
Podle wikipedie to nemá žádný vztah k našemu datu, je to prostě jen počet vteřin od 00:00:00 1.1.1970.Pokud je to takto definované, pak to při nastavení timezone, kde byly přestupné sekundy, minimálně na mém systému počítá blbě.
~> echo $(( `date --date "2015-06-30 23:59:59+0000" +%s` - `date --date "2015-07-01 00:00:01+0000" +%s` )) $(( `date --date "2015-05-31 23:59:59+0000" +%s` - `date --date "2015-06-01 00:00:01+0000" +%s` )) -2 -2
Souhlasím s tím, že zobrazování je pak někdy dost zábava a v té hodině, která na podzim v lokálním zobrazení neexistuje je to pravdu oříšek. Ale ukládání lokálního času je špatně.Časové údaje v různých časových zónách jsou navzájem bez problémů převoditelné. 28. 3. 2016 12:00:00 CEST == 28. 3. 2016 11:00:00 CET == 28. 3. 2016 10:00:00 UTC. I to 28. 3. 2016 11:00:00 CET je platný čas, akorát se to takhle nepoužívá, protože se tou dobou používá CEST. Také je jednoznačně určeno, kdy se jako lokální čas používá CET a kdy CEST (např. letos je to od 27. 3. 2016 01:00:00 UTC do 30. 10. 2016 00:59:59 UTC). Takže jediná „zábava“ může nastat, když čas zobrazujete bez časové zóny a potřebujete zobrazit čas mezi 30. 10. 2016 01:00:00 UTC a 30. 10. 2016 01:59:59 UTC – je vhodné alespoň pro tohle období časovou zónu zobrazit. Vzhledem k tomu, že ty časové údaje v různých zónách jsou navzájem převoditelné, není nic špatného na ukládání lokálního času – pokud ho ukládáte s časovou zónou. Špatné je ukládání bez časové zóny, a to ať už je ten čas v jakékoli zóně. Častým příkladem jsou logy – i když tam máte čas v UTC, ale není to tam uvedeno, je to komplikace, protože musíte dodatečně zjišťovat, v jaké zóně je ten čas uváděn.
Z hlediska fyzikálních a astronomických měření je posouvání CLOCK_REALTIME o sekundu vpřed a vzad zcela špatně.To je ale špatná implementace. Správná implementace je taková, že po 01:59:59 CEST následuje 01:59:60 CEST a teprve po té 02:00:00 CEST. Problém je, že spousta software neumí pracovat s minutou delší než 60 sekund, a spousta software ukládá čas jako počet sekund (případně mili- nebo mikrosekund) od definovaného času, přičemž předpokládá, že každá minuta má právě 60 sekund. V takovém případě je samozřejmě pro ten software jediná možnost tu přestupnou sekundu zatajit a „nenápadně“ posunout hodiny.
Neviem ako ostatní, ale keď som chodil do práce posun času mi celkom pomáhal. Pred presunom zo zimného na letný som aj tak vstval cca o hodinu skôr, takže zmena bola celkom vhod. Zase v zime bolo vstávanie ráno o rovnakom čase stále ťažšie a zase prechod na zimný čas to napravil.
Asi nejvíc mi vadí že se ráno při cestách do práce znovu dostaneme do "zvířecího času". Do doby krátce před východem slunce, kdy už není tma ale ještě není vidět.
Toto práve zmena času rieši. Choďte do práce o 08:00, vtedy je to v pohode v letnom aj zimnom čase. Ak by sa do práce chodilo o 08:00 terajšieho letného času tak bez zmeny času by to bolo v zime práve pred svitaním.
Lenže to nie je problém posúvania času. Ak sa časy nastavia dobre tak to práve predchádza týmto problémom. Že je niekto blbec na to som si už zvykol. Teda vlastne nezvykol, akurát som si jedného dňa povedal, že na to kašlem a dal som výpoveď :-P
Ako zrušenie CEST pomôže bežnému človeku pracujúcemu povedzme od 08:00 ráno (povedzme, že nemá možnosť flexibilnej pracovnej doby)? V lete bude slnko výchádzať viacej než 4h pred príchodom do práce. Je to dosť málo času na nejaké tie domáce rekonštrukčné práce. Západ slnka zase v najlepšom prípade okolo 19:00 čo je zase od príchodu z práce málo času. Potom je riešenie na dohode so zamestnávateľom nech mení pracovnú dobu (ehm a sme zase pri skokovej zmene času) čím krásne rozbijeme príchod do práce tým, ktorí využívajú hromadnú dopravu.
Doplňte si čas podľa seba. Otázka zostáva.
Skokovú zmenu o hodinu som mal v lete niekoľko krát (individuálna dohoda aby som mohol začínať o 08:00 (zima) 07:00, 06:00, 05:00 podľa východu slnka). Zdá sa mi prirodzenejšia riadiť sa podľa slnka než nejakou umelo zavedenou veličinou (hodiny).
Čo sa týka zvyšku, áno, hlavne u vlakov / lietadiel je problém, ale nič, čo by spoločnosti nedokázali zvládnuť. Zmena sa hlavne deje cez víkend, takže pre tých, ktorí pracujú pondelok - piatok sa to nedotkne. Ak ide o nejaké elektronické systémy tam časové zóny fungujú už dávno, zrušením letného času sa akurát budú musieť preprogramovať.
V lete bude slnko výchádzať viacej než 4h pred príchodom do práce.Asi lepší když bude vycházet 4 hodiny před než 5 hodin před.
To si riešte s ľuďmi, ktorí chcú používať UTC.
Horší to mají ti s pevnou pracovní dobou, v šest v montérkách ve fabrice a bez keců.
Je mi to víceméně jedno, ale popuzuje mne ta hysterie, která se kolem toho pravidelně dvakrát do roka rozpoutá, a nesmyslná tvrzení v diskusích. Abych pravdu řekl, ať přemýšlím, jak přemýšlím, napadají mne jen dva efekty, které jsou mi trochu nepříjemné:
Oboje je v podstatě jen krátkodobá nepříjemnost, protože to první za pár týdnů zase pomine a to druhé se jen asi o měsíc uspíší. Abych kvůli tomu běhal někde s transparentem nebo se rozhorloval v diskusích, to rozhodně ne.
Co se týká mé reakce, ta se týkala poslední věty vašeho příspěvku. Po čtyřech dnech volna jsem si opravdu nemohl dovolit v práci dřímat. A pokud jsem nebyl úplně ve formě, vůbec to nesouviselo s letním časem, ale s tím, že jsem včera večer bojoval s webovou aplikací pro podání daňového přiznání podstatně déle, než jsem měl v plánu.
Bedňa, včera 21:15:
Dnes sa v práci všetkým driemalo.
Michal Kubeček, včera 21:17:
Mluvte za sebe…
Bedňa, včera 23:03:
Nebudem hovoriť za druhých
Děkuji. :-)
Nemám slov.
Tak to se moc často nevidí. :-)
Aká skoková zmena? Stačí si plynule posúvať čas vstávania tak, aby to pred zmenou času bolo cca o hodinu skôr.
Mně připadá že se nedokáží domluvit lidi s pevnou a pružnou pracovní dobou. Těm co mají pružnou je to úplně jedno a vyhovuje jim to "tak jak to je", čímž vlastně tvrdí že změnu nechtějí.
Nebo zrušíme lokální časy a celej svět pojede podle UTC
to ale neresi posun casu, tedy to co je tím mysleno, ze jdete do prace dřív, aby jste ráno nečumel tři hodiny z okna na špačky,Čumět ráno tři hodiny na špačky - to je ta mentální zdravotní sprcha, kterou kvůli tomu idiotskému šoupání časem tak tragicky postrádám.. Nejenom prací je živ člověk!
ISSN 1214-1267, (c) 1999-2007 Stickfish s.r.o.