¿Deben los servidores tener su zona horaria establecida en GMT / UTC? [cerrado]

Puede que esto no sea un gran problema para las tiendas más pequeñas que solo tienen uno o unos pocos sitios, pero para organizaciones más grandes esto es algo que tengo curiosidad.

¿Cuáles son las ventajas y desventajas de tener todo / la mayoría de su servidor en UTC? Sin duda ayudaría en la presentación de informes y el registro centralizado. También con correlación de eventos para la resolución de problemas o la auditoría de seguridad. Uno tampoco tendría que preocuparse tanto por los cambios del horario de verano.

Una desventaja podría ser que la programación de eventos automáticos (por ejemplo, cron) puede tomar un poco de mayo si desea que ejecute algo a las "4 AM" en la hora geográfica local. Para la máquina Unix-y aún podría tener usuarios en la zona horaria local configurando "TZ" en / etc / profile, pero para los usuarios de Windows que RDesktop en un servidor (por cualquier razón), ¿están atrapados mirando UTC?

Como con la mayoría de las cosas, "depende".

• ¿Están todos sus administradores / usuarios en la misma zona horaria? Quizás su TZ sería apropiado.
• ¿Las máquinas interactúan con el entorno local? TZ local podría ser bueno.
• ¿Se extraen todos los registros a una ubicación central para su análisis? UTC podría ayudar allí.
• ¿Las máquinas se comunican entre sí de maneras donde el tiempo importa? UTC podría ayudar a prevenir problemas tontos de desajuste.
• ¿El proveedor del sistema operativo (más probable para el equipo de red) tiene una sugerencia? Considere eso.
• ¿Te molestará el horario de verano? Utiliza UTC.
• ¿Qué crees que hará tu vida más fácil? Usa eso.

He hecho todas las opciones (local, UTC, arbitraria pero coherente) y prefiero la "hora local a la oficina en casa para todas las máquinas", ya que allí estaban los administradores y los usuarios, a pesar de que las máquinas estaban dispersas por todo el mundo .

Configuramos todo a GMT, simplifica la correlación de los archivos de registro en los sistemas.

Pero creo que deberíamos abandonar las zonas horarias, y todos usar GMT para todo.

Como otros han dicho, depende. Ha intervenido un grupo muy grande con una larga y vasta experiencia en este asunto. El grupo son las fuerzas militares de todo el mundo y utilizan UTC (GMT).

Otra cosa a tener en cuenta. Si estos sistemas son compatibles con el código de la aplicación, debe saber si las aplicaciones conocen la zona horaria. En algunos de los foros de programación en los que participo, sugiero que las fechas / horas siempre se almacenen en UTC en la base de datos, y le doy al usuario final la opción de cómo ven la fecha / hora.

Trabajo para una empresa de hosting muy grande y tenemos centros de datos en todo el mundo. Generalmente establecemos el tiempo de la máquina en el tiempo del centro de datos local, y luego usamos la zona horaria donde se encuentra todo nuestro personal de soporte como el tiempo universal al que se convierten las cosas cuando se usan herramientas, etc.

Como otros han dicho, no hay una respuesta correcta, pero ese es el método que usamos :)

La política aquí dice que todas las máquinas están sincronizadas con su zona horaria local (es decir, ubicación física). Lo único complicado es correlacionar las entradas del registro de eventos (Windows Machiens), ya que el tiempo es nlocal; de todos modos, la mayoría de los otros archivos de registro escriben el tiempo en UTC.

pero para los usuarios de Windows que RDesktop ingresan a un servidor (por cualquier razón), ¿están atrapados mirando UTC?

No estoy totalmente seguro, pero creo que sí, la zona horaria es lógicamente una configuración de nivel de máquina.

Tenemos máquinas ubicadas físicamente en una zona horaria que se configuran con 3 horas de anticipación debido a la aplicación que admiten.

También tenemos desarrolladores que crean software que espera una sincronización de menos de cinco segundos entre servidores, desarrolladores que dependen implícitamente del tiempo de AD para la sincronización, y que no se molestan en escribir rutinas de verificación de errores o manejo para casos sin sincronización, y que afirman que las fallas posteriores son culpa de los administradores por no mantener el tiempo de red al estándar que estaban imaginando.

No hagas lo que hicimos. Simplemente te hará amargo.

Solo para agregar a la discusión, tenemos oficinas dispersas por todo el mundo y cada una de ellas tiene su propio conjunto de servidores web, de aplicaciones y de bases de datos, con diferentes ramas de aplicaciones para cada uno de ellos, por lo que una zona horaria local es una buena idea. hablando en todo el país. Para los servidores de EE. UU., Nos dirigimos hacia la hora central para que todas las ubicaciones coincidan con nuestro centro de datos principal, ya que el uso de diferentes zonas horarias para servidores de aplicaciones y bases de datos está haciendo que los desarrolladores tengan dificultades.

La aplicación Yeller publicó recientemente una publicación de blog que aconseja a todos los administradores de sistemas que utilicen UTC. Aquí hay un extracto:

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.

Bromas aparte, básicamente dice que usar solo UTC significa no molestarse con el horario de verano (DST) y los errores que esto provoca.