Fusi orari locali su server considerati dannosi? [chiuso]

Sono curioso di sapere quali siano le esperienze di altri amministratori con i fusi orari, nel contesto di server amministrati a distanza. Nella mia carriera ho incontrato diverse convenzioni;

1. Usa sempre, sempre, sempre UTC.
2. Usa sempre, sempre, il fuso orario di qualsiasi sede HQ di base.
3. Utilizzare l'ora locale delle persone che si trovano ad amministrare.
4. Utilizzare l'ora locale della posizione del server.

In alcuni punti, ho incontrato convenzioni multiple e contrastanti. La mia preferenza è stata quella di utilizzare UTC, sempre - senza ora legale. Ma per un motivo o per l'altro, sembra che la maggior parte delle persone preferisca utilizzare un concetto di ora locale, con l'ora legale. Sebbene sembri una questione tecnica semplice, le discussioni sul cambiamento delle convenzioni sembrano sempre orientarsi verso scismi religiosi.

Che cosa stai usando? Quali ritieni siano i vantaggi e gli svantaggi di ciascun approccio?

• L'orologio hardware deve essere sempre UTC. Sempre.
• Il fuso orario come impostazione può essere qualsiasi cosa sia conveniente. Generalmente. A volte dovrebbe anche essere UTC.

Alcuni motivi per cui UTC è carino:

• Le regole sull'ora legale cambiano e gli aggiornamenti non avvengono sempre in modo tempestivo. UTC lo fa andare via.
• Quando è necessario confrontare i registri di server in posizioni diverse, UTC stabilisce uno standard comune eccezionale.
• In genere, quando i server si trovano in posizioni diverse, le persone o le applicazioni o entrambe devono gestire le conversioni temporali mentre eseguono, diciamo, inserimenti di database. Se hai una singola conversione (in UTC), è molto più facile ottenere il giusto rispetto a se devi convertire da una TZ a un'altra, variando per server, TZ.

Preferisco l'opzione 4. È responsabilità delle applicazioni in esecuzione su un server decidere se archiviare o meno i valori di DateTime in UTC.

Inoltre, quando un server registra i log degli eventi di sistema, è bello poter correlare gli eventi locali con le voci dei log. Ad esempio, se un data center segnala un'interruzione della rete nell'ora locale, è possibile identificare facilmente eventuali problemi che si sono verificati senza dover convertire i valori dell'ora nella propria testa.

No, no, mille volte no.

Ci sono due tipi di programmatori ... Coloro che capiscono che localtime deve essere utilizzato per esposizione / formattazione scopo solo , e quelli che si stanno dipingendo in un angolo ... e sono la pittura con kerosene .

Tutti gli eventi dovrebbero essere registrati in UTC e i risultati convertiti in ora locale solo per mostrarli agli utenti. Dannati sono quelli che non riescono a fare questo, e doppiamente-dannati sono coloro che utilizzano localtime in un formato che scarta le informazioni fuso orario (sto guardando te , Oracle DBA).

Pensalo come un controllo di contaminazione ... Se converti un timespec in localtime e poi fai qualcosa che non lo emette in STDOUT, il tuo programma non dovrebbe uscire solo con un errore fatale, ma anche cancellare la tua fonte per insegnare tu una lezione.

Quando viene data la scelta, mi piace mantenere l'orologio del BIOS su UTC ma l'ora del server attuale come ora locale. Non abbiamo presenza di più fusi orari, quindi il timestamp log unificato non è il problema che sarebbe per, diciamo, 3M.

Nella mia azienda, avevamo tutti i server in un'unica TZ fino a quest'anno. Ora abbiamo server in 3 nuovi fusi orari. Tutto il server funziona con il nostro fuso orario locale. Questo è piuttosto utile per l' analisi dei log , soprattutto perché abbiamo distribuito siti Web in esecuzione su 3 fusi orari.

Tuttavia, in un caso speciale , abbiamo lasciato un server con il nostro cliente TZ. Si suppone che l'applicazione sia attiva per gran parte della giornata e le attività di manutenzione sono in genere configurate per l'esecuzione durante la "notte". Inizialmente, abbiamo impostato il server nella nostra TZ ma le attività di manutenzione rallentavano troppo le cose per i nostri amati clienti "lavoriamo quando dormi" ...

UTC è anche un'opzione molto bella. A meno che le persone non facciano sempre riferimento al fuso orario locale quando guardano i registri (che è il caso qui).

Eseguo tutti i miei server su UTC e converto quanto mi viene in mio controllo il più presto possibile.

L'unica eccezione finora è stata un server asterisco, che ho dovuto lasciare all'ora locale. Modificandolo in UTC si è completamente rotto l'asterisco. (È su 1.6, speriamo che questo non sia un problema quando riesco ad aggiornarlo entro la fine dell'anno.)