Question Le fuseau horaire des serveurs doit-il être défini sur GMT / UTC? [fermé]


Ce n'est peut-être pas un problème pour les plus petits magasins qui ne possèdent qu'un ou plusieurs sites, mais pour les grandes organisations, c'est une chose qui m'intrigue.

Quels sont les avantages et les inconvénients d’avoir tout / la plupart de votre serveur en UTC? Cela aiderait certainement à la création de rapports et à la journalisation centralisée. Egalement avec corrélation d'événements pour le dépannage ou l'audit de sécurité. De plus, il n’aurait pas à s’inquiéter autant des changements d’heure avancée.

Un inconvénient pourrait être que la planification d’événements automatisés (par exemple, cron) prenne un peu de temps si vous voulez qu’elle exécute quelque chose à 4 heures du matin, à l’heure locale et géographique. Pour les ordinateurs Unix-y, vous pouvez toujours avoir des utilisateurs dans le fuseau horaire local en définissant "TZ" dans / etc / profile, mais pour les utilisateurs Windows qui RDesktop sur un serveur (pour quelque raison que ce soit), sont-ils bloqués à regarder l'UTC?


22
2017-10-15 12:50


origine


Il existe un fil de discussion similaire (plus ancien) chez sage-members: mailman.sage.org/pipermail/sage-members/2010/msg00592.html - adamo
Et bien sûr, puisque vous avez posté la question sur les membres de sage aussi, le (nouveau) fil de discussion mailman.sage.org/pipermail/sage-members/2010/msg01194.html :) - adamo
UTC un fuseau horaire pour les gouverner tous ... - Jarrod Roberson


Réponses:


Comme avec la plupart des choses, "ça dépend".

  • Tous vos administrateurs / utilisateurs sont-ils dans le même fuseau horaire? Peut-être que leur TZ serait approprié.
  • Les machines interagissent-elles avec l'environnement local? La TZ locale pourrait être bonne.
  • Tous les journaux sont-ils tirés vers un emplacement central pour analyse? UTC pourrait aider là-bas.
  • Les machines communiquent-elles les unes avec les autres de manière à ce que le temps compte? UTC pourrait aider à prévenir les problèmes de discordance stupides.
  • Est-ce que le fournisseur de système d'exploitation (plus susceptible d'utiliser un équipement réseau) a une suggestion? Considérez cela.
  • Est-ce que DST vous importunera? Utilisez UTC.
  • Que pensez-vous va vous rendre la vie plus facile? Utiliser ça.

J'ai utilisé toutes les options (locale, UTC, arbitraire mais cohérente) et je préfère "l'heure locale au bureau à domicile pour toutes les machines", car c'est là que se trouvaient les administrateurs système et les utilisateurs, même si les machines étaient dispersées dans le monde entier. .


19
2017-10-15 13:41



Bien mis - j'ajouterais quelques critères supplémentaires. 1) Si vous avez des organisations de support dans plusieurs fuseaux horaires, UTC partout évitera probablement la confusion (dans ce cas, le fait de tout définir sur le fuseau horaire du "siège social" ne fera qu'irriter les employés des autres bureaux; peu importe la confusion qui en découle. 2) Si vous devez traiter avec des fournisseurs internationaux tels que des opérateurs de télécommunication, beaucoup d’entre eux travaillent en UTC; ne pas avoir à convertir les horodatages de vos journaux lors de leur envoi vous fera gagner beaucoup de temps. - Murali Suriar
J'ai travaillé sur différents fuseaux horaires avec différents serveurs. Nous avons eu de sérieux problèmes avec un projet une fois où les données étaient stockées avec le fuseau horaire des serveurs défini sur DST et GMT .. pas facile à corriger. Pas facile du tout. UTC est votre ami :) - John Hunt


Nous réglons tout sur GMT, cela simplifie la corrélation des fichiers journaux entre systèmes.

Mais je pense que nous devrions laisser tomber les fuseaux horaires et utiliser tous le GMT pour tout.


6
2017-10-15 16:25





Comme d’autres l’ont dit, cela dépend. Un très grand groupe avec une longue et vaste expérience dans ce domaine a pesé. Les forces militaires du monde entier utilisent le temps UTC (GMT).

Une autre chose à considérer. Si ces systèmes prennent en charge le code d'application, vous devez savoir si les applications sont sensibles au fuseau horaire. Dans certains des forums de programmation auxquels je participe, je suggère que la date / l'heure soit toujours stockée au format UTC dans la base de données et donne à l'utilisateur final la possibilité de voir comment il voit la date / l'heure.


3
2017-10-19 12:34





Je travaille pour une très grande société d'hébergement et nous avons des centres de données dans le monde entier. Nous définissons généralement l'heure de la machine sur l'heure du centre de données local, puis nous utilisons le fuseau horaire dans lequel se trouve tout notre personnel de support. Il correspond à l'heure universelle à laquelle les éléments sont convertis lors de l'utilisation d'outils, etc.

Comme d'autres l'ont dit, il n'y a pas une seule bonne réponse, mais c'est la méthode que nous utilisons :)


2
2017-10-15 15:09





La politique indique ici que toutes les machines sont timzonées vers leur fuseau horaire local (c’est-à-dire leur emplacement physique). La seule chose qui soit délicate est de corréler les entrées du journal des événements (windows machiens) car l’heure est donnée à nlocal - la plupart des autres fichiers journaux écrivent l’heure au format UTC.

mais pour les utilisateurs Windows que RDesktop   dans un serveur (pour une raison quelconque),   sont-ils coincés avec regarder UTC?

Pas tout à fait sûr, mais je pense que oui - le fuseau horaire est logiquement un paramètre de niveau machine.


1
2017-10-15 13:14





Nous avons des machines physiquement situées dans un fuseau horaire et qui sont configurées pour 3 heures à l'avance en raison de l'application qu'elles prennent en charge.

Nous avons également des développeurs qui créent des logiciels qui attendent une synchronisation inférieure à cinq secondes entre les serveurs, des développeurs qui dépendent implicitement du temps de synchronisation pour la synchronisation, et qui ne se sont pas souciés d'écrire des routines de vérification des erreurs ou de traitement pour les cas non synchronisés, et qui affirment: que les échecs ultérieurs sont la faute des administrateurs pour ne pas maintenir le temps de réseau à la norme qu'ils imaginaient.

Ne fais pas ce que nous avons fait. Cela vous rendra juste amer.


1
2017-10-15 17:11





Pour ajouter à la discussion, nos bureaux sont répartis dans le monde entier et chacun d’entre eux possède son propre ensemble de serveurs Web, d’applications et de bases de données, avec différentes branches d’application pour chacun d’entre eux. Le fuseau horaire local est donc une bonne idée. parlant à travers le pays. Pour les serveurs américains, nous nous dirigeons vers l'heure centrale pour que tous les emplacements correspondent à notre centre de données principal, car l'utilisation de fuseaux horaires différents pour les serveurs d'applications et les bases de données donne un temps difficile aux développeurs.


1
2017-09-27 16:15





L’application Yeller a récemment publié un article de blog conseiller à tous les administrateurs système d’utiliser UTC. Voici un extrait:

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.

Blagues mises à part, cela signifie essentiellement que l'utilisation uniquement du temps UTC signifie ne pas s'embarrasser de l'heure d'été (DST) et des bugs que cela entraîne.


0
2018-01-21 16:30