¿Las zonas horarias locales en los servidores se consideran perjudiciales? [cerrado]

Tengo curiosidad por saber cuáles son las experiencias de otros administradores con las zonas horarias, en el contexto de los servidores administrados de forma remota. En mi carrera me he encontrado con varias convenciones;

1. Siempre, siempre, siempre use UTC.
2. Siempre, siempre, usa siempre la zona horaria de donde sea que esté la base HQ.
3. Use la hora local de las personas que están administrando.
4. Use la hora local de la ubicación del servidor.

En algunos lugares, me he encontrado con convenciones múltiples y conflictivas. Mi preferencia ha sido usar UTC, siempre, sin horario de verano. Pero por una razón u otra, parece que la mayoría de la gente prefiere usar algún concepto de hora local, con horario de verano. Aunque parece una cuestión técnica directa, las discusiones sobre las convenciones cambiantes siempre parecen tender hacia cismas religiosos.

¿Que estas usando? ¿Cuáles considera que son las ventajas y desventajas de cada enfoque?

• El reloj de hardware siempre debe ser UTC. Siempre.
• La zona horaria como configuración puede ser lo que sea conveniente. Generalmente. A veces también debería ser UTC.

Algunas razones por las que UTC es bueno:

• Las reglas del horario de verano cambian, y las actualizaciones no siempre ocurren de manera oportuna. UTC hace que esto desaparezca.
• Cuando se necesitan comparar registros de servidores en diferentes ubicaciones, UTC es un gran estándar común.
• Por lo general, cuando los servidores se encuentran en diferentes ubicaciones, las personas o las aplicaciones, o ambas, deben lidiar con las conversiones de tiempo al realizar, por ejemplo, inserciones de bases de datos. Si tiene una única conversión (a UTC), es mucho más fácil acertar que si tiene que convertir de una TZ a otra, que varía según el servidor, TZ.

Prefiero la opción 4. Es responsabilidad de las aplicaciones que se ejecutan en un servidor decidir si almacenar los valores de DateTime en UTC o no.

Además, cuando un servidor registra los registros de eventos del sistema, es bueno poder correlacionar eventos locales con entradas de registro. Por ejemplo, si un centro de datos informa una interrupción de la red en la hora local, puede identificar fácilmente cualquier problema que ocurra sin tener que convertir los valores de tiempo en su cabeza.

No, no, mil veces no.

Hay dos tipos de programadores ... Los que entienden que la hora local se debe utilizar para visualizar / fines de formato única , y los que están pintando a sí mismos en una esquina ... y ellos están pintando con queroseno .

Todos los eventos deben registrarse en UTC, y los resultados deben convertirse a tiempo local solo para mostrarlos a los usuarios. Malditos son aquellos que no pueden hacer esto, y doblemente condenado-son los que utilizan hora local en un formato que descarta la información de zona horaria (estoy mirando a usted , Oracle DBA).

Piense en ello como una comprobación de contaminación ... Si convierte una especificación de tiempo en tiempo local y luego hace algo con ella que no la emite a STDOUT, su programa no solo debe salir con un error fatal, sino que también debe eliminar su fuente para enseñar Eres una lección.

Cuando se me da la opción, me gusta mantener el reloj del BIOS en UTC pero la hora real del servidor como hora local. No tenemos presencia en varias zonas horarias, por lo que la marca de tiempo de registro unificada no es el problema que sería para, digamos, 3M.

En mi empresa, teníamos todos los servidores en una sola TZ hasta este año. Ahora tenemos servidores en 3 nuevas zonas horarias. Todo el servidor se ejecuta con nuestra zona horaria local. Esto es bastante útil para el análisis de registros , especialmente porque hemos distribuido sitios web que se ejecutan en las 3 zonas horarias.

Sin embargo, en un caso especial , hemos dejado un servidor con nuestro cliente TZ. Se supone que la aplicación está activa la mayor parte del día y las tareas de mantenimiento generalmente se configuran para ejecutarse durante la "noche". Al principio, configuramos el servidor en nuestra TZ, pero las tareas de mantenimiento estaban ralentizando demasiado las cosas para nuestros queridos clientes "trabajamos cuando duermes" ...

UTC también es una muy buena opción. A menos que las personas siempre se refieran a la zona horaria local al mirar los registros (que es el caso aquí).

Ejecuto todos mis servidores en UTC, y convierto los que están bajo mi control tan pronto como puedo.

La única excepción hasta ahora ha sido un servidor de asterisco, que tuve que dejar a la hora local. Cambiarlo a UTC rompió por completo el asterisco. (Está en 1.6, espero que esto no sea un problema cuando llegue a actualizarlo más adelante este año).