Un sistema Linux ha effettivamente due orologi: uno è il "Real Time Clock", alimentato a batteria (conosciuto anche come "RTC", "orologio CMOS", o "orologio Hardware") che scandisce il tempo quando il sistema è spento ma non è utilizzato quando è funzionante. L'altro è l'"orologio di sistema" (chiamato anche "orologio del kernel" o "orologio software") che è un contatore software basato sugli interrupt del timer. Non esiste quando il sistema non è in funzione, per cui deve essere inizializzato dall'RTC (o da qualche altra fonte) al boot. I riferimenti all'"orologio" nella documentazione di ntpd si riferiscono a quello di sistema, non all'RTC.
I due orologi deviano dall'ora reale a ritmi differenti, perciò gradualmente i rispettivi orari differiranno sempre più tra loro, ed anche dal tempo "reale". Il modo più semplice per mantenerli precisi è di misurare i tassi di deviazione, e applicare dei fattori di correzione nel software. Poichè l'RTC è usato solo quando il sistema non è attivo, il fattore di correzione è applicato quando l'orario viene letto all'avvio, usando clock(8) o hwclock(8). L'orologio di sistema puņ essere corretto regolando la quantità di tempo di cui l'orologio di sistema è portato avanti ad ogni interrupt del timer, usando adjtimex(8).
Una rude alternativa ad adjtimex(8) è far avviare clock(8) o hwclock(8) a cron periodicamente, per sincronizzare l'orario di sistema all'RTC (corretto). Questa strada era raccomandata nella pagina man clock(8), e funziona se lo si fa abbastanza spesso da non causare grossi "salti" nell'orario di sistema, ma adjtimex(8) èuna soluzione più elegante. Alcune applicazioni potrebbero inoltre lamentarsi se l'orario "salta" all'indietro.
Il passo successivo in accuratezza è utilizzare un programma come ntpd per leggere periodicamente l'orario da un server di orario di rete o da un'orologio radio, ed aggiustare continuamente il passo dell'orologio di sistema cosicché i tempi corrispondano sempre. Se hai una connessione ad una rete sempre attiva all'avvio del tuo sistema, puoi ignorare completamente l'RTC e usare ntpdate (incluso nel pacchetto ntpd) per inizializzare l'orologio di sistema da un server -- o un server locale su LAN, o un server remoto su Internet. Se qualche volta però non hai la connessione, o se ti serve che l'ora sia precisa durante la sequenza di avvio e prima della connessione alla rete, allora dovrai mantenere preciso anche l'RTC.
Potrebbe sembrare ovvio che se usi un programma come ntpd, puoi sincronizzare l'RTC all'orologio di sistema (corretto). Questa risulta però essere una cattiva idea se il sistema starà spento per più di pochi minuti, perché questa procedura interferirà con i programmi che applicano il fattore di correzione all'RTC all'avvio.
Se il sistema è attivo 24 ore su 24 e 7 giorni su 7 ed è sempre riavviato immediatamente dopo essere stato (eventualmente) spento, puoi semplicemente regolare l'RTC dall'orologio di sistema giusto prima di spegnere la macchina. L'RTC non devierà significativamente nel tempo speso per il riavvio, perciò non ti servirà conoscere il suo tasso di deviazione.
Naturalmente il sistema potrebbe bloccarsi imprevedibilmente, così alcune versioni del kernel sincronizzano l'RTC all'orologio di sistema ogni 11 minuti se quest'ultimo è stato riaggiustato da un altro programma. L'RTC non devierà abbastanza in 11 minuti da fare alcuna differenza, ma se il sistema è spento abbastanza a lungo da far deviare significativamente l'RTC, allora hai un problema: i programmi che applicano le correzioni all'RTC hanno bisogno di sapere *esattamente* quando l'RTC è stato resettato l'ultima volta, ed il kernel non registra questa informazione da nessuna parte.
Alcuni "tradizionalisti" di unix potrebbero chiedersi perché qualcuno potrebbe lasciare attivo un sistema Linux per meno di 24 ore al giorno e sette giorni alla settimana, ma alcuni di noi utilizzano un sistema dual-boot, con un altro OS in funzione per un certo tempo, o usano Linux su portatili che devono essere spenti per preservare le batterie quando non sono utilizzati. Altre persone, semplicemente, non vogliono lasciare i PC attivi senza sorveglianza per lunghi periodi di tempo (anche se abbiamo sentito ogni sorta di argomentazioni in favore di questa linea). Perciò l'"ogni 11 minuti" diventa un bug.
Questa "caratteristica/bug" sembra comportarsi in maniera differente in diverse versioni del kernel (e forse anche in diverse versioni di xntpd e ntpd), così se stai usando sia ntpd che hwclock, potrebbe essere necessario controllare cosa il tuo sistema realmente fa. Se non puoi trattenere il kernel dal resettare l'RTC, potresti dover far funzionare il sistema senza un fattore di correzione.
La parte del kernel che regola questo aspetto si trova in /usr/src/linux-2.0.34/arch/i386/kernel/time.c (dove il numero di versione nel path sarà dato dalla versione del kernel che stai utilizzando). Se la variabile time_status è impostata a TIME_OK allora il kernel scriverà l'ora sull'RTC ogni 11 minuti, altrimenti lo lascerà stare. Le chiamate a adjtimex(2) (come quelle che vengono effettuate da ntpd e timed, ad esempio) potrebbero abilitare questo parametro. Le chiamate a settimeofday(2) imposteranno time_status a TIME_UNSYNC, che dice al kernel di non regolare l'RTC. Non ho trovato della vera documentazione su questo aspetto.
Ho sentito che alcune versioni del kernel potrebbero aver problemi con gli "sleep mode" che spengono la CPU per risparmiare energia. La soluzione migliore è di tenere il kernel aggiornato, e segnalare ogni problema alle persone che lo aggiornano.
Se ottieni risultati bizzarri dall'RTC potresti avere un problema hardware. Alcuni chip RTC includono una batteria al litio che può esaurirsi, e alcune schede madri hanno la possibilità di inserire una batteria esterna (assicurati che i jumper siano impostati correttamente). La stessa batteria mantiene la RAM CMOS, ma l'orologio assorbe più energia ed è probabile che abbia problemi prima. Se le cose strane riguardano l'orologio di sistema, potrebbe esserci un problema con gli interrupt.
l'"orologio di sistema" di Linux effettivamente non fa altro che contare il numero di secondi trascorsi dal 1 Gennaio 1970, ed è sempre in UTC (Coordinated Universal Time - Orario Universale Coordinato; o GMT, Greenwich Mean Time - Ora Media di Greenwich, che è tecnicamente differente ma abbastanza vicino da far usare indifferentemente i due termini dagli utenti normali). L'UTC non cambia al cambiare dell'ora legale-- quello che cambia è la conversione tra UTC e local time (l'orario locale). La traduzione in local time è operata da funzioni di libreria che vengono linkate nelle varie applicazioni.
Questo ha due conseguenze: primo, ogni applicazione che necessiti di conoscere il local time avrà anche bisogno di conoscere in che fuso orario ci si trovi, e se vige l'ora legale o meno (vedi la sezione successiva per maggiori dettagli sui fusi orari). Secondo, non c'è nessuna funzionalità nel kernel per cambiare l'orologio di sistema o l'RTC al variare dell'ora legale, perché l'UTC non cambia. Perciò i sistemi che funzionano solo con Linux dovrebbero avere l'RTC impostato sull'UTC, non sul local time.
Comunque, molte persone utilizzano sistemi dual-boot con altri OS, i quali si aspettano che l'RTC contenga il local time; perciò, hwclock ha bisogno di sapere se il tuo RTC sia impostato sul local time o sull'UTC, per poi convertirlo nei secondi trascorsi dal 1 Gennaio 1970 (UTC). Questo ancora non fornisce alcun supporto automatico per i cambiamenti periodici dell'RTC dovuti all'ora legale, perciò il cambiamento dev'essere operato dagli altri OS (questa è l'eccezione che si diceva prima alla regola di lasciar che un solo programma cambi l'orario dell'RTC).
Sfortunatamente, non ci sono flag nell'RTC o nella RAM CMOS che indichino che si sta utilizzando l'ora legale piuttosto di quella solare, perciò ogni OS registra quest'informazione in propri luoghi, dove non è visibile agli altri OS. Questo significa che hwclock deve presumere che l'RTC contenga sempre il local time corretto, anche se l'altro OS non è stato mai avviato dall'ultimo cambio d'orario stagionale.
Se Linux è in funzione quando succede il cambio d'orario stagionale, l'orologio di sistema non ne è affetto, e le applicazioni effettueranno la conversione corretta. Ma se Linux deve per qualche ragione essere riavviato, l'orologio di sistema sarà impostato all'orario registrato nell'RTC, che sarà di un'ora sbagliato, finché l'altro OS (di solito Windows) avrà la possibilità di essere avviato.
Non c'è soluzione a questo problema, ma Linux non va in crash troppo spesso, perciò la ragione più probabile per un reboot su un sistema dual-boot è proprio che si debba avviare l'altro OS. Ma fai attenzione se sei una di quelle persone che chiudono Linux quando non lo utilizzi per un po'-- se non hai avuto la possibilità di avviare l'altro OS dall'ultima variazione di orario, l'RTC sarà spostato di un ora finché non lo farai.
Alcuni altri documenti affermano che impostare l'RTC su UTC permette a Linux di gestire correttamente l'ora legale. Questo non è proprio sbagliato, ma non la dice tutta-- finché non riavvii, non importa che orario c'è nell'RTC (e perfino se la sua batteria si esaurisce). Linux manterrà l'orario corretto in ogni caso, fino al prossimo riavvio. In teoria, se riavvii una volta all'anno (il che non è irragionevole, per Linux), l'ora legale potrebbe cambiare due volte e se l'RTC fosse rotto anche da molti mesi non lo noteresti neppure, perché l'orologio di sistema sarebbe rimasto corretto per tutto il tempo. Ma dal momento che non puoi prevedere quando riavvierai, è meglio avere l'RTC impostato sull'UTC se non usi un'altro OS che richieda il local time.
Il chip RTC della Dallas Semiconductors (che è un sostituto per il chip della Motorola utilizzato negli IBM AT e cloni) può effettivamente effettuare da sè il passaggio all'ora legale e viceversa, ma questa caratteristica non è utilizzata perché le date di passaggio sono codificate dentro l'hardware stesso del chip e non possono essere cambiate. Le versioni correnti effettuano il cambiamento alla prima domenica di Aprile e all'ultima di Ottobre, ma versioni precedenti usavano date differenti (e ovviamente questo non funziona in altri stati che negli USA). L'RTC è inoltre spesso integrato nel "chipset" della scheda madre (piuttosto che essere un chip separato), e tra questo tipo di chip non so quali abbiano tale caratteristica.
Probabilmente hai impostato il tuo fuso orario correttamente quando hai installato Linux. Ma se devi modificarlo per qualche ragione, o se le leggi locali riguardanti l'ora legale cambiano (come fanno di frequente in alcuni stati), allora dovrai sapere come reimpostarlo. Se il tuo orario di sistema è sbagliato di un numero esatto di ore rispetto all'ora reale, potresti appunto avere un problema di fuso orario (o di impostazione dell'ora legale).
Il fuso orario e le informazioni sull'ora legale sono registrate in /usr/share/zoneinfo (o /usr/lib/zoneinfo nei sistemi più datati). Il fuso orario locale è determinato da un link simbolico da /etc/localtime su uno di questi file; per modificare il fuso basta cambiare il link. Se le date per l'ora legale del tuo stato sono cambiate, dovrai modificare direttamente il file.
Puoi usare anche la variabile d'ambiente TZ per cambiare il fuso corrente, il che è pratico se lavori accedendo in remoto a una macchina che si trova sotto un altro fuso. Vedi anche la pagina man di tzset e tzfile.
Tutto ciò è ottimamente riassunto a http://www.linuxsa.org.au/tips/time.html
Se non ti serve un'accuratezza a meno di un secondo, hwclock(8) e adjtimex(8) potrebbero essere tutto ciò che ti serve. È facile essere tentati dagli orologi radio e simili, ma io ho usato il programma clock(8) per anni con eccellenti risultati. D'altro canto, se hai molte macchine su una LAN potrebbe risultare comodo far loro sincronizzare gli orologi automaticamente l'una con l'altra. E potrebbe essere divertente giocherellare con il resto della roba anche se non ne hai propriamente bisogno.
Su macchine che utilizzano solo Linux, imposta l'RTC su UTC (o GMT). Su sistemi dual-boot che richiedono che nell'RTC ci sia il local time, sappi che se devi riavviare Linux dopo il cambio di orario stagionale, l'orologio potrebbe essere sfasato di un'ora, finché non avrai la possibilità di avviare l'altro OS. Se hai più di due OS, assicurati che uno solo di essi operi l'impostazione dell'ora legale.