Pozor ovšem na to, že to může způsobit problém při dualbootu s Windows, která zase počítají jen s hodinami v lokálním čase.
Windows už dlouho umožňují používat v BIOSu UTC (i když dříve o nebylo úplně bez chyb) – dá se to přenastavit v registrech. Viz třeba popis na ArchWiki – UTC in Windows.
Ta poznámka, že dříve to nebylo úplně bez chyb je prakticky zbytečná, protože ve stejné době (před 10 -12 lety a více) jsem míval stejné problémy s posunem času i v linuxu ... bylo zabugované obojí (Win i Linux) a optimální nastavení (tedy s funkčním local time který znal UTC) neexistovalo nikde.
*Linux míval v té době problémy opačné (převod na local), i když minimálně co pamatuji tak ne přímo na úrovni OS (resp. tam býval, tam jsem míval, UTC obecně, všude), ale v knihovnách (a tedy vlastních programech). Pokud jsem chtěl dostat localtime, tak jsem si musel vše ošéfovat sám a někdy musel někdy nesměl (nevím proč, občas blblo a dával dvojnásobnou) předem nastavít zónový posun (zónové variables), tuším via tzset (fungoval-li) nebo ručně. A letní a zimní čas byl ještě horší. Býval to opruz. Vše se, na obou systémech, spravilo až během posledních 5-10 let a už je OK i v praxi a funguje jak interně, tak různé OS mezi sebou. Když se jednou dobře nastaví.
Pokud vím, systémový čas v Linuxu je vždy v UTC a nejde to změnit. Pokud jste tam nastavil lokální čas, nedivím se, že jste s tím pak měl problémy. Navíc tady je řeč o načtení času z BIOSu při startu Linuxu a jeho uložení při vypínání/uspání, což jsou jednorázové akce a dělá je ta jedna utilita hwclock, takže chyby v jiných programech s tím nesouvisí.
Pozor, mixují se tu dvě věci. UTC Linux a jeho možnost převodu do localtime (jak známe dnes a jak to dříve prakticky nefungovalo, protože převod na lokal si musel každý dělat po svém, protože i "oficiální" knihovní věci blbly - byl v tom fakt bordel). Na to jsem narážel v mé poznámce. Že se člověk musel smířit s UTC a občas se mu někde, sem tam, objevil (správný) local.
A pak byla druhá možnost, kterou nyní zmiňujete - já ji nevyužíval, ale v okolí byla. Pokud tenkrát někdo chtěl mít linux a na něm _spolehlivý_ localtime (tedy i letní čas a podobně) (typicky domácí použití), nezbylo mu než si hw time (systémový) nastavit na lokální. A (pro programy co chtěly navíc převádět po svém) se tvářit, že je v Londýně.
Paradoxně, ona druhá možnost byla tenkrát spolehlivější, pro domácí použití (kde nebyla nutná interakce PC s okolím na systémové úrovni). Byla spolehlivější jak při dualboot (a to nejen s win), tak při tom, že člověk i na linuxu (pro domácí BFU) vždy viděl, i v čase starých souborů, "správný" čas (z pohledu čitelnosti pro běžné lidi). Doma se neřešily nekonzistentní problémy s logy, na to se kašlalo, ale třeba se hledalo, zda to zapsal dospělý (po práci) nebo děti (odpoledne), časy fotek (neřku při převody času z exif, kde si většina na foťáku nastavuje local) že nebyly posunuté o 2h. A podobně.
Ano, mixujete tu dvě věci. Na systému s Linuxem existují celkem tři časy – 1. čas RTC, tedy hardwarových hodin počítače (pokud je počítač má), dále 2. systémový čas (čas hodin jádra, u kterého se očekává, že je v UTC) a pak 3. lokální čas (který se odvozuje ze systémového času a z nastaveného časového pásma).
Vy popisujete problémy s převodem mezi 2 a 3 (já teda používám Linux asi 20 let a problémy s časem jsem nezaznamenal, ale věřím, že některé aplikace fungovaly špatně). V dualbootu s Windows byl ale problém mezi 1 a 2. Jakmile se ale čas z RTC při startu systému načetl do linuxového systémového času, byla a je úplně jedno, v čem RTC běží.
Jinak vždycky dávalo smysl mít RTC v UTC, protože v RTC není uvedená časová zóna, a když nemáte časovou zónu, jediná smysluplná zóna je UTC. Výjimkou byly právě počítače s hloupým OS jako DOS nebo Windows, které očekávaly, že RTC běží v lokální časové zóně. Což samozřejmě dělalo problémy i při dualboot dvou Windows, protože když časová zóna není uložená v RTC, musely si jí Windows ukládat někdo bokem v systému – no a pak samozřejmě první Windows poslední neděli v říjnu ráno zjistily, že RTC mají v SELČ ale správná zóna je SEČ, tak posunuly RTC o hodinu. Pak jste spustil druhé Windows, ty měly také poznamenáno, že čas v RTC je v SELČ a posunuly hodiny ještě jednou.
Hej, nastavil si si HW hodiny na lokalny cas, a zdalo sa ti to OK. A potom si bootol do Linuxu v to pekne rano, kedy sa predoslu noc menil cas z letneho na standardny (alebo opacne), linux zmenil systemovy cas a zapisal tu zmenu do HW hodin. A potom si neskor rebootol do Windoze... a tie spravili uplne to iste a tiez to cele posunuli o hodinu, lebo si mysleli, ze HW hodiny su (stale) o hodinu mimo. Takze sa ti to 2x za rok rozosralo. Tak tomu hovorim "spolahlivejsia moznost", LOL.
Nic, zapomeňte. Já o voze Vy o koze.
Tedy, že ta poznámka, že to dříve nebylo bez chyb, se mi zdála zavádějící - ve smyslu že vyzněla, jako bychom si na to měli dát pozor. Když už o tom něco explicitně zmiňujete.
Nemusíme dávat pozor. Stejně jako nemusíme nyní dávat pozor na 1000+1 věcí z té doby, vč. těch co jsem pro změnu uvádě jál. Nedůležité informace. A zbytečně jsem offtopic akademickou diskusí na toto téma méně znalé čtenáře v zblbl. Teď (tedy už cca 10 let) už je vše ok.
Podívejte se na tu odkazovanou wiki stránku, kde máte odkazy na některé chyby Windows, pokud jsou RTC v UTC. Byly to reálné chyby, kvůli kterým někdo dualboot s Windows XP provozoval tak, že RTC měl v lokálním čase. To byl důvod, proč se při dualbootu řešilo, zda používat UTC nebo lokální čas – kdyby to i ve Windows fungovalo bez problémů, nikdo by to neřešil a v dnešním článku by se to vůbec neobjevilo. O žádných takových chybách v hwclock nevím, a to ani v době před dvanácti lety – ani vy jste žádnou takovou chybu nepopsal. Psal jste pouze o chybách v aplikacích, které se ale netýkají přenosu času mezi RTC a systémovými hodinami, o kterém byla řeč.