Fuseaux horaires locaux sur les serveurs considérés comme nuisibles? [fermé]

Je suis curieux de savoir quelles sont les expériences des autres administrateurs avec les fuseaux horaires, dans le contexte des serveurs administrés à distance. Dans ma carrière, j'ai rencontré plusieurs conventions;

1. Toujours, toujours, utilisez toujours UTC.
2. Toujours, toujours, utilisez toujours le fuseau horaire du siège de la base.
3. Utilisez l'heure locale des personnes qui administrent.
4. Utilisez l'heure locale de l'emplacement du serveur.

À certains endroits, j'ai rencontré des conventions multiples et contradictoires. Ma préférence a toujours été d'utiliser UTC, sans heure d'été. Mais pour une raison ou une autre, il semble que la plupart des gens préfèrent utiliser un concept d'heure locale, avec l'heure d'été. Bien que cela semble être une question technique simple, les discussions sur le changement des conventions semblent toujours tendre vers des schismes religieux.

Qu'est-ce que vous utilisez? Quels sont selon vous les avantages et les inconvénients de chaque approche?

• L'horloge matérielle doit toujours être UTC. Toujours.
• Le fuseau horaire comme paramètre peut être celui qui convient. Habituellement. Parfois, cela devrait également être UTC.

Quelques raisons pour lesquelles UTC est agréable:

• Les règles d'heure d'été changent et les mises à jour ne se produisent pas toujours en temps opportun. UTC fait disparaître cela.
• Lorsque les journaux de serveurs situés à des emplacements différents doivent être comparés, UTC constitue un excellent standard commun.
• En règle générale, lorsque les serveurs sont situés à des emplacements différents, les personnes ou les applications, ou les deux, doivent gérer les conversions de temps lors, par exemple, des insertions de base de données. Si vous avez une seule conversion (en UTC), il est beaucoup plus facile de bien faire que si vous devez convertir d'une TZ à une autre, en fonction du serveur, TZ.

Je préfère l'option 4. Il incombe aux applications exécutées sur un serveur de décider de stocker ou non les valeurs DateTime en UTC.

De plus, lorsqu'un serveur enregistre les journaux des événements système, il est agréable de pouvoir corréler les événements locaux avec les entrées de journal. Par exemple, si un centre de données signale une interruption du réseau à l'heure locale, vous pouvez facilement identifier les problèmes qui se sont produits sans avoir à convertir les valeurs d'heure dans votre tête.

Non, non, mille fois non.

Il existe deux types de programmeurs ... Ceux qui comprennent que l'heure locale ne doit être utilisée qu'à des fins d'affichage / de formatage , et ceux qui se peignent dans un coin ... et ils peignent avec du kérosène .

Tous les événements doivent être enregistrés en UTC et les résultats convertis en heure locale uniquement pour les afficher aux utilisateurs. Damned sont ceux qui ne parviennent pas à le faire, et doublement damnés sont ceux qui utilisent localtime dans un format que les rejets les informations de fuseau horaire (je regarde vous , Oracle CBM).

Pensez-y comme à une vérification de la souillure ... Si vous convertissez une heure locale en heure locale et que vous faites quoi que ce soit qui ne soit pas émis vers STDOUT, votre programme devrait non seulement quitter avec une erreur fatale, mais aussi supprimer votre source pour enseigner vous une leçon.

Quand on me donne le choix, j'aime garder l'horloge du BIOS sur UTC mais l'heure réelle du serveur comme heure locale. Nous n'avons pas de présence sur plusieurs fuseaux horaires, donc l'horodatage des journaux unifiés n'est pas le problème que ce serait pour, disons, 3M.

Dans mon entreprise, nous avions tous les serveurs dans une seule TZ jusqu'à cette année. Nous avons maintenant des serveurs dans 3 nouveaux fuseaux horaires. Tous les serveurs fonctionnent avec notre fuseau horaire local. Ceci est assez utile pour l' analyse des journaux , d'autant plus que nous avons distribué des sites Web sur les 3 fuseaux horaires.

Cependant, dans un cas particulier , nous avons laissé un serveur à notre client TZ. L'application est censée être active la majeure partie de la journée et les tâches de maintenance sont généralement configurées pour s'exécuter pendant la "nuit". Au début, nous avons installé le serveur dans notre TZ, mais les tâches de maintenance ralentissaient trop les choses pour nos chers clients "nous travaillons quand vous dormez" ...

L'UTC est également une très bonne option. À moins que les gens ne se réfèrent toujours au fuseau horaire local lorsqu'ils consultent les journaux (ce qui est le cas ici).

J'exécute tous mes serveurs sur UTC et je convertis tous ceux qui sont sous mon contrôle dès que possible.

La seule exception jusqu'à présent a été un serveur astérisque, que j'ai dû laisser à l'heure locale. Le changer en UTC a complètement brisé l'astérisque. (Il s'agit de la version 1.6, j'espère que ce ne sera pas un problème lorsque je le mettrai à niveau plus tard cette année.)