Dotaz: freezy použiva localtime, ikdyž ma nastavene UTC

[Migi]

Bry večir, skoro ráno. Před pár dny jsem si vygooglil návod jak nastavit Windows, aby hardwarove hodiny (tedy hodiny biosu) považovalo za UTC čas, v důsledku čehož by byli hodiny zobrazované uživateli dopočítávány pomocí timezone. Co se Windows týče, funguje to skvěle. Problém je kupodivu s Linuxem, přesněji s Debianem Wheezy, přesněji s jedním z nich. Dlouhodobě porovozuji tripleboot:

• Windows 7
• Wheezy, ale pro odlišení mu říkejme Freezy - můj hlavní systém
• Wheezy, ten druhý wheezy

Windows tedy považují HW hodiny za UTC - funkční.
Wheezy (ten druhý) v /etc/default/rcS nastavene UTC=yes, timezone Europe/Praha - funkční. Freezy je nějaký zmatený. Nastavení stejné jako u wheezyho, nicméně pokud jsou HW hodiny skutečně nastavene (nastavoval jsem přímo v biosu) na UTC, je freezy o dvě hodiny pozadu(oproti UTC), zatimco Windows a Wheezy zobrazují čas korektně. Pokud si ve freezym vypíšu date, jsem tedy vůči UTC o dvě hodiny pozadu. Pokud si ale vypíši hodiny biosu (sudo hwclock -r), zobrazí se korektní UTC čas. z napovedy hwclock:

Funkce: -r, --show zjistí a vypíše aktuální stav hodin reálného času --set nastaví RTC na hodnotu zadanou přepínačem --date -s, --hctosys nastaví systémový čas podle hodin reálného času -u, --utc hodiny reálného času jdou v UTC

Pokud si tedy vypíši hwclock -u, zobrazí se mi náš čas, ktery bych rad v systemu. Zvolím tedy hwclock -u -s, abych do systemových hodin dostal požadovaný čas, což se také povede. Jen pro kontrolu, hwclock -r opět zobrazi UTC (tedy dve hodiny nazpet oproti našemu času). Problem nastava po rebootu. Windows a Wheezy totiž začnou ukazovat o dvě hodiny navic oproti našemu času. To se neni čemu divit, protože když vlezu do biosu, namisto požadovaneho UTC času (dvě hodiny nazpet vuči našemu lokalnimu času) je tam (právě) náš lokalni čas. Tudíž se nedivím že windows a wheezy jdou, dle nastavení, o další dvě hodiny dopředu. Podivné je chování freezyho. Ačkoli ten ma take nastavené, že hardwarove hodiny ma považovat za UTC čas, zobrazí naše hodiny bez problemu. Tedy v panelu mam požadovaný čas, mam ho i v date, nicmene ho dostanu i po vypsani hwclock -r. Tudíž je zřejmé, že navzdory nastavení pracuje freezy s lokalnim časem, který navzdory nastavení uklada přimo do hardwarovych hodin, což zpusobuje posun ve zbylych systemech. Freezy je na disku zhruba o nekolik mesiců dele nez wheezy, drive na nem kratce běželo NTP. A teď babo raď.

Odpovědi

[Petr Šobáň]

Mě se na fedoře kdysi stalo něco podobného, mršila mi čas pak jsem přišel na to že tam byl napsán špatně skript který při ukončení a startu předpokládal lokální čas v HW hodinách a nekoukal se na nastavení. (tehdá jsem do skriptu dopsal parametru -u k hwclock.

A nebo může být nastavená špatně časová zona (každý uživatel může mít jinou) jakou má root? Jaká je nastavená pro systém v /etc/timezone

[Migi]

hans@Intrepid:~$ cat /etc/timezone Europe/Prague

[Migi]

UPDATE:

Chvíli jsem si hrál s příkazem hwclock a vypadá to, že freezy přecijen začal používat UTC. Nevím, přesně které parametry a v jakem pořadi jsem použil, nicméně mezi nimi byly --systz a --utc --systohc v totožne pořadi.

Postupně tedy:

1. hwclock --systz (nastaveni systemovych hodin dle nastavene timezone)
2. hwclock --utc -systohc (systemove hodiny se uloži do hardwarových s tím, že ještě předtím proběhne přepočet na UTC

V tomto okamžiku mi všechny tři systémy ukazují náš (lokální) čas ,nicméně v biosu je skutečně o dvě hodiny méně, tedy Universal Time (UTC). To jsem si ověřil postupným nabootováním do všech 3 systémů, zkontrolovaním v nich zobrazovaných hodin a kontrolou hodin biosu mezi bootováním jednotlivých systémů. Vše, jak se zdá, v pořádku. Ani jeden system neuložil "do biosu" lokální čas.

Poznámka: Příkaz hwclock -r, který dle nápovědy "zjistí a vypíše aktuální stav hodin reálného času", stále ukazuje lokální čas. Osobně jsem dle popisu z nápovědy měl za to, že zkrátka dobře vypíše přesně to, co bych momentálně viděl v biosu. Očividně tomu tak není, doporučuji tedy návštěvu biosu, než se spoléhat na hwclock -r. S přepínačem k tomuto příkazu přidáte ještě parametr --utc a dostanete náš lokální čas, pak je "pravděpodobně" (tzn. si to myslím) vše v pořádku. Jaký přepočet používá samotný parametr -r netuším.

[Migi]

Oprava předposlední věty:

Pokud k tomuto příkazu přidáte ještě parametr --utc a přesto dostanete náš lokální čas, pak je "pravděpodobně" (tzn. si to myslím) vše v pořádku.

Asi budu umlácen argumenty typu "máš čist náhled komentáře", takže ani nebudu spílat nad absencí "upravit komentář" u komentů bez reakce.

[petr_p]

Pokud hwclocku nedáš --utc nebo --local, tak se řídí konfigurací uloženou v /etc/adjtime. Tam se konfigurace zapisuje s každým zavoláním hwclock --systohc.

Nevím, jak tam máš instalované jednotlivé operační systémy, ale tipl bych si, že jak se střídaly, tak nesouhlasil obsah hardwarových hodin a /etc/adjime v daném kořenovém souborovém systému.

[petr_p]

Můžu se zeptat na ten návod pro Windows? Kdysi když jsem se tím zabýval, tak problém byl, že Windows sice čas správně převáděly, ale když jsem si testoval přechod mezi letním a zimním časem, tak ho stejně pokazily.

[Migi]

postupoval jsem podle tohoto blogu

Mám to pár dní na desktopu dualboot sedmičky a wheezy, (stanice nema pristup na internet) a ted na svem notebooku, tudiz s prechodem na letni/zimni cas zatim zadna zkusenost. Musim však dodat, že behem googleni vyše odkazovanehío postupu jsem narazil na par threadu pojednavajicich o problemech s timto prechodem.