date - titling - ¿Alguna vez hay una buena razón para almacenar tiempo no en UTC?
remove date latex (7)
Me pregunto si hay alguna buena razón para almacenar la información de tiempo en otra cosa que no sea UTC (GMT)? Creo que esta es una regla sólida para toda la ingeniería de software. La conversión a la hora local es simplemente una traducción que se realiza en la capa de la interfaz de usuario para fines de visualización. También he visto casos en los que se necesita la traducción para implementar un algoritmo correctamente (para manejar los cambios de fecha de medianoche, etc.).
Cuando esté seguro de que solo se va a utilizar la hora local.
En general me parece mejor usar UTC. A veces es posible que necesite una hora local. Entonces prefiero ir con información de zona horaria UTC +.
En general, los tiempos pueden ser extremadamente difíciles para eventos repetitivos, y debe analizar cuidadosamente los casos de uso.
Imagine una reunión recurrente, todos los martes a las 9:00 am. Si el horario de verano cambia, la reunión todavía debería ocurrir a las (9) a las 9:00 am.
Pero no agregar a la reunión algunos chicos en Francia. Para ellos la reunión es a las 6:00 pm. Y cambian el DST por una regla diferente.
Cuando cambias el horario de verano, no lo hacen, así que por un tiempo (hasta que Francia cambie el horario de verano) alguien debería estar "apagado": tu reunión será a las 10 am y la suya permanecerá a las 6 pm, o mantendrá la tuya a las 9 am y moverá la suya a las 5 pm. No hay otra manera, las computadoras no tienen nada que ver con eso.
¿Cómo decidirá una aplicación quién debe ser "arreglado"? ¿Es el grupo con más miembros? (¿1 hombre en Estados Unidos contra 20 en Francia?) ¿O se trata de la importancia de la persona? (¿Y si el 1 en Estados Unidos es el CEO?)
¿Cómo almacenas esa información? Mi mejor solución es utilizar UTC + una "zona horaria maestra". Los usuarios en la "zona horaria maestra" ganan (permanecen fijos).
Las cosas pueden ser bastante difíciles, pero en general he encontrado que la UTC resuelve más problemas que los que presenta.
En un sistema integrado, bien podría recibir el tiempo de una fuente en algún tipo de forma de "época pasada".
Si la hora se actualiza con relativa frecuencia y se muestra con poca frecuencia, entonces es mejor que la almacene de la misma forma que se le proporciona y que solo la convierta para mostrarla cuando sea necesario.
En general, sin embargo, UTC es el camino a seguir a menos que haya otras consideraciones.
Las alarmas y las tareas programadas a veces se almacenan en la hora local para que no se vean afectadas por los cambios del horario de verano o de la zona horaria.
Yo diría que es dependiente de la aplicación. Trabajo en modelos de física espacial de la ionosfera y la magnetosfera. Trabajamos con hora local magnética, almacenando fechas y horas como Días Julianos Modificados .
UTC es un estándar de mantenimiento del tiempo que tiene la precisión y la precisión del TAI , pero con segundos de salto agregados a intervalos irregulares para permitirle seguir de cerca el tiempo solar medio (UT1).
Si el sistema con el que está trabajando no puede manejar los segundos de salto, entonces la Oficina Internacional de Poids et Mesures recomienda que se utilice TAI en lugar de UTC.
Consulte: http://tycho.usno.navy.mil/leapsec.html
Alguna vez Estoy seguro de que hay buenas razones en algunos casos aislados. En general, sin embargo, almacenar UTC es mucho mejor que la hora local, por lo que trataría a UTC como la posición predeterminada a menos que haya alguna consideración especial.