I server devono avere il fuso orario impostato su GMT / UTC? [chiuso]

Questo potrebbe non essere un grosso problema per i negozi più piccoli che hanno solo uno o pochi siti, ma per le organizzazioni più grandi questo è qualcosa di cui sono curioso.

Quali sono i pro e i contro che hanno tutto / la maggior parte del tuo server in UTC? Sarebbe sicuramente di aiuto nel reporting e nella registrazione centralizzata. Anche con correlazione di eventi per la risoluzione dei problemi o il controllo della sicurezza. Inoltre, non ci si dovrebbe preoccupare tanto dei cambiamenti dell'ora legale.

Uno svantaggio potrebbe essere che la pianificazione di eventi automatici (ad es. Cron) potrebbe richiedere un po 'di tempo se si desidera che esegua qualcosa alle "4 AM" nell'ora locale e geografica. Per la macchina Unix-y potresti avere utenti nel fuso orario locale impostando "TZ" in / etc / profile, ma per gli utenti Windows che RDesktop si trova su un server (per qualsiasi motivo), sono bloccati a guardare UTC?

Come per la maggior parte delle cose, "dipende".

• Tutti i tuoi amministratori / utenti sono nello stesso fuso orario? Forse la loro TZ sarebbe appropriata.
• Le macchine interagiscono con l'ambiente locale? La TZ locale potrebbe essere buona.
• Tutti i registri vengono estratti in una posizione centrale per l'analisi? UTC potrebbe aiutare lì.
• Le macchine comunicano tra loro in modi in cui il tempo conta? UTC potrebbe aiutare a prevenire problemi di disallineamento sciocchi.
• Il fornitore del sistema operativo (più probabile per dispositivi di rete) ha un suggerimento? Considera che.
• L'ora legale ti infastidirà? Usa UTC.
• Cosa pensi ti renderà la vita più facile? Usa quello.

Ho fatto tutte le opzioni (locale, UTC, arbitrario ma coerente) e preferisco il "fuso orario locale all'ufficio di casa per tutte le macchine" poiché è lì che si trovavano gli amministratori di sistema e gli utenti, anche se le macchine erano sparse in tutto il mondo .

Impostiamo tutto su GMT, semplifica la correlazione dei file di registro tra i sistemi.

Ma penso che dovremmo abbandonare i fusi orari e usare tutti GMT per tutto.

Come altri hanno già detto, dipende. Un gruppo molto ampio con una lunga e vasta esperienza in materia è stato molto rilevante. Il gruppo è costituito dalle forze militari di tutto il mondo e usano UTC (GMT).

Un'altra cosa da considerare. Se questi sistemi supportano il codice dell'applicazione, è necessario sapere se le applicazioni sono in grado di riconoscere il fuso orario. In alcuni dei forum di programmazione a cui partecipo suggerisco che data / ora siano sempre archiviate in UTC nel database e offro all'utente finale la possibilità di vedere la data / ora.

Lavoro per una grande società di hosting e disponiamo di datacenter in tutto il mondo. Generalmente impostiamo l'ora della macchina sull'ora del datacenter locale, quindi utilizziamo il fuso orario in cui tutto il nostro personale di supporto si trova come il tempo universale in cui le cose vengono convertite quando si utilizzano strumenti, ecc.

Come altri hanno già detto, non esiste una risposta giusta, ma questo è il metodo che usiamo :)

La politica qui dice che tutte le macchine sono timzonate al loro fuso orario locale (cioè posizione fisica). L'unica cosa complicata è correlare le voci del registro eventi (windows machiens) poiché l'ora è data nlocal - la maggior parte degli altri file di registro scrive comunque l'ora in UTC.

ma per gli utenti Windows che RDesktop si trova su un server (per qualsiasi motivo), sono bloccati a guardare UTC?

Non sono del tutto sicuro, ma penso di si - il fuso orario è logicamente un'impostazione a livello di macchina.

Abbiamo macchine localizzate fisicamente in un fuso orario impostate per 3 ore in anticipo a causa dell'applicazione che supportano.

Abbiamo anche sviluppatori che sviluppano software in attesa di una sincronizzazione inferiore ai cinque secondi tra i server, sviluppatori che si affidano implicitamente al tempo di AD per la sincronizzazione e che non si preoccupano nemmeno di scrivere procedure di controllo degli errori o di gestione per casi non sincronizzati e che affermano che i guasti successivi sono colpa degli amministratori per non aver mantenuto il tempo di rete allo standard che stavano immaginando.

Non fare quello che abbiamo fatto. Ti renderà semplicemente amaro.

Solo per aggiungere alla discussione, abbiamo uffici sparsi in tutto il mondo e ognuno di essi ha il proprio set di server web, applicazioni e database, con rami di applicazione diversi per ognuno di essi, quindi il fuso orario locale è una buona idea mentre parlando in tutto il paese. Per i server statunitensi, ci stiamo dirigendo verso il fuso orario centrale affinché tutte le località corrispondano al nostro datacenter principale, poiché l'utilizzo di fusi orari diversi per i server delle app e i DB sta dando agli sviluppatori un momento difficile.

L'app Yeller ha recentemente pubblicato un post sul blog in cui si consiglia a tutti gli amministratori di sistema di utilizzare UTC. Ecco un estratto:

Use UTC. Use UTC. Use UTC. Use UTC. Use UTC. Use UTC. Use UTC. Use UTC. Use UTC. Use UTC. Use UTC. Use UTC. Use UTC. Use UTC.

Scherzi a parte, in pratica si dice che usare solo UTC significa non preoccuparsi dell'ora legale (DST) e dei bug che ciò comporta.