Dice Absatz: "La única forma razonable de manejarlo es ponerlo según la (poca) información disponible y la sabiduría (o intuición) de los que están en el tema…"
La unica forma razonable de manejarlo es NO PONER nada de lo cual no se este seguro. El paquete tzdata es CRITICO y se debe manejar con parametros CRITICOS. Esa "horita" en muchos servidores fue un gran problema. Hablemos de MRTG, hablemos de RRDTOOL, hablemos de arruinar meses de estadísticas, todo por no manejar el paquete de husos horarios, que como repito es CRITICO (como el de OpenSSL, digamos), como corresponde.
Arturo "Buanzo" Busleiman
En general el software para el cual es crítico mantener un reloj correcto mantiene la información en UTC y el huso horario sólo lo utiliza para mostrar la hora local adaptada para el usuario (de hecho, si distintos usuarios configuraran en forma diferente su $TZ, les mostraría distinto las horas)… Entiendo que en particular RRD utiliza UTC internamente, pero no estoy seguro.
Es una suerte utilizar unix o linux donde normalmente el reloj del equipo se mantiene en UTC y el localtime simplemente indica cuántas horas hay que sumarle o restarle al reloj antes de mostrárselo al usuario… Windows tiene la espantosa costumbre de mantener la hora del equipo según una hora local lo cual es un inconveniente ante cambios en las reglas de cambio de hora (ver las espantosas e incompletas instrucciones para arreglar este bolonqui).
De hecho, si la criticidad llega al nivel del segundo, entonces convendría tener el reloj en TAI y no en UTC, para evitar una especie de «salto hacia atrás» de un segundo que se producirá, por ejemplo, el próximo 31 de diciembre a las 0:00 UTC
Con respecto a la razonabilidad o falta de razonabilidad de criterios a que hace referencia Buanzo, la respuesta era tan larga que la puse en mi blog
—
Mariano Absatz – el Baby