localization - planisferio - ¿Manejando zonas horarias en el almacenamiento?

zonas horarias del mundo (12)

¿Almacenar todo en GMT?

¿Almacenar todo tal como se ingresó con un desplazamiento incrustado?

Hacer las matemáticas cada vez que render?

Mostrar tiempos relativos "hace 1 minuto"?

Así que ejecuté un pequeño experimento con el servidor MSSQL.

Creé una tabla y agregué una fila con la zona horaria localizada actual (Australia). Luego cambié mi fecha y hora para ser GMT y agregué otra fila.

Incluso aunque esas filas se agregaron con una separación de alrededor de 10 segundos, aparecen en el servidor SQL como si estuvieran separadas por 10 horas.

Si nada más, al menos me dice que debería almacenar las fechas de manera concomitante, lo que para mí agrega peso al argumento para almacenarlas como GMT.

MS Dynamics almacena GMT y luego a un nivel de usuario conoce su zona de tiempo en relación con GMT. Luego muestra elementos en su zona horaria.

Solo pensé en tirar eso porque ese es un grupo bastante grande en MS y así es como decidieron manejarlo.

Me gusta almacenar en GMT y mostrar solo relativos ("hace unos 10 segundos", "5 meses atrás"). Los usuarios no necesitan ver marcas de tiempo reales para la mayoría de los casos de uso.

Sin duda hay excepciones, y una aplicación individual puede tener muchas de ellas, por lo que no puede ser una respuesta "única". Las cosas que necesitan una fuerte capacidad de auditoría (por ejemplo, la votación) y los sistemas en los que el tiempo forma parte del dominio del discurso (astronomía, investigación científica) pueden exigir que se muestren las marcas de tiempo verdaderas al usuario.

La mayoría de las aplicaciones, sin embargo, son más fáciles de entender con un tiempo relativamente simple.

Personalmente, no veo ninguna razón para no almacenar todo en GMT y luego utilizar la zona horaria local de los usuarios para mostrar la hora en lo que se refiere a ellos.

Si desea mostrar la hora relativa, obviamente todavía necesita tiempo y hacer una traducción, pero si desea hacer la traducción, creo que GMT sigue siendo su mejor opción.

Usualmente solo uso el tiempo de Unix. no necesariamente seguro en el futuro, pero funciona bastante bien.

Siempre almacene en GMT (o UTC). Desde allí, es fácil convertirlo a cualquier valor de zona horaria local.

La respuesta, como siempre, es "depende".

Depende de lo que describa con el tiempo y de cómo se le proporcionaron los datos. La clave para decidir cómo almacenar los valores de tiempo es decidir si está perdiendo información al descartar la zona horaria, además de no sorprender a sus usuarios.

El almacenamiento de datos en un UTC time_t tiene ventajas definidas: es un int único, lo que permite una clasificación rápida y un almacenamiento sencillo.

Veo que el problema se divide en áreas específicas:

Información histórica
Futuro, datos a corto plazo
Datos futuros a largo plazo

Con las siguientes subclases en cada uno:

Sistema proporcionado
Usuario proporcionado

Miremos uno a la vez.

Sistema proporcionado : recomendaría ejecutar sistemas en UTC, luego se evita el problema de la zona horaria y, nuevamente, no se ve pérdida de información (siempre es UTC).

Datos históricos : son cosas como archivos de registro del sistema, estadísticas de proceso, seguimiento, fechas / horas de comentarios, etc. Los datos no van a cambiar y el descriptor de zona horaria no cambiará de forma retroactiva. Para este tipo de datos, no se pierde información al almacenar la información en UTC independientemente de la zona horaria en la que se haya proporcionado. Por lo tanto, descarte la zona horaria.

Futuro, datos a largo plazo : estos son eventos que están lo suficientemente lejos en el futuro o seguirán sucediendo. Si se mantienen el tiempo suficiente, las descripciones de la zona horaria están garantizadas. Un buen ejemplo de este tipo de datos es "La reunión de gestión semanal". Se trata de datos que se ingresan una vez y se espera que continúen funcionando a perpetuidad. Para estos valores, es importante determinar si se trata de un sistema o un usuario. Para los datos proporcionados por el usuario, el tiempo debe almacenarse con la zona horaria del creador, cualquier otra cosa da como resultado la pérdida de información. ¡Esta pérdida de información se hace evidente cuando la definición de la zona horaria cambia y se muestra la hora al creador que tiene un valor completamente diferente!

Como ha indicado Bwooce, existe cierta confusión cuando el creador y el espectador se encuentran en diferentes zonas horarias. En ese caso, esperaría que la aplicación indique qué valores de tiempo se han movido debido a un cambio de zona horaria desde sus ubicaciones anteriores.

Futuro, datos a corto plazo : se trata de datos que se convertirán rápidamente en históricos, o solo válidos durante un corto período de tiempo. Los ejemplos pueden ser temporizadores de intervalos, transiciones de clasificación, etc. Para estos datos, dado que la probabilidad de que la definición cambie entre la creación del valor y el tiempo que pasa a ser histórica, es posible salirse con la caída de la zona horaria. Sin embargo, descubrí que estos valores tienen la mala costumbre de convertirse en "datos futuros a largo plazo".

Una vez que haya decidido almacenar la zona horaria, se debe tener cuidado con la forma en que se almacena.

No almacene la zona horaria como un desplazamiento, o el descriptor completo.

Si almacena una zona horaria como un desplazamiento, ¿qué hace si la zona horaria cambia? ¿Pasas por el sistema y haces un cambio general en los datos existentes? Si lo hace, ahora ha hecho que los valores históricos sean incorrectos. Buenos ejemplos de esta falla son Oracle e iCal. Oracle almacena información de zona horaria como un desplazamiento de UTC e iCal incluye el descriptor completo para la zona horaria de creación.

Almacenarlo como un nombre.

Esto permite que la definición de la zona horaria cambie sin tener que modificar los valores existentes que tiene. Hace que la clasificación sea más difícil, ya que cualquier índice que se genere puede no ser válido si los datos de la zona horaria cambian.

Si los desarrolladores continúan almacenando todo en UTC, independientemente de la zona horaria, seguiremos viendo los problemas que hemos visto con el último lote de cambios de zona horaria.

En una organización, las secretarias tenían que imprimir los calendarios de sus equipos antes de la fecha de ahorro de luz diurna y luego imprimirlos después del cambio. Finalmente, compararon los dos y volvieron a crear todas las citas que se habían movido. Por supuesto, se perdieron varias, y hubo varias semanas de dolor hasta que se alcanzó la fecha de ahorro de luz del día anterior y los tiempos volvieron a ser correctos.

Prefiero almacenar todo con la zona horaria. el cliente puede decidir, de qué manera debe presentarse más adelante. mi biblioteca favorita para la conversión es la base de datos PostgreSQL .

Almacenar todo en GMT / UTC me parece lo más lógico. A continuación, puede mostrar la fecha y la hora en cada zona horaria que desee.

Algunos ceveats:

Si un tiempo solo se especifica como una hora de reloj de pared y esa es la representación principal, entonces no es un tiempo absolutamente especificado. Deberías (y no puedes) convertirlo en cualquier representación de GMT. EG 9:00 a.m. todas las mañanas. En otras palabras: este no es (fecha) hora.
Si guarda una fecha y hora de una cita futura, debe usar el desplazamiento a GMT especificado por la zona horaria de entrada y el momento en el tiempo mismo . Entonces, si se trata de una cita en verano realizada en invierno, por ejemplo, en Europa occidental, es +2: 00, aunque la compensación normal (horario de invierno) es +1: 00. Esto resolverá el problema del calendario que Bwooce mencionó.
Por supuesto, lo mismo que se aplica al uso del desplazamiento correcto mientras se convierte a GMT se aplica cuando se convierte de nuevo a una fecha y hora en cualquier zona horaria en particular.

Afortunadamente, cuando se usa correctamente, el tipo DateTime (.NET) se ocupa de todos los detalles sangrientos de mantener los calendarios, etc. para usted y todo esto debería ser muy fácil cuando sepa cómo funciona.

Eche un vistazo aquí, el w3c ha hecho un excelente trabajo respondiendo la pregunta.

Mira los casos de uso.

http://www.w3.org/TR/timezone/

Tenga en cuenta que recomiendan almacenar las fechas como UTC, no GMT, GMT está sujeto al horario de verano.

Josh está completamente correcto arriba, pero tengo una advertencia sutil para explicar. Este es un caso sin una respuesta correcta sobre eventos futuros y zonas horarias.

Considere el caso de una cita repetitiva. Ocurre en GMT 0000 (por simplicidad), que es 1200 NZST (hora estándar de Nueva Zelanda) y 1000 AEST en Sydney Australia.

Cuando el horario de verano entra en vigencia en una zona, ¿qué debería ocurrirle a la cita? Deberia:

1a. Si el cambio de TZ está en la zona del "propietario" de la cita (¿quién lo reservó?), Entonces intente permanecer en la misma hora del reloj de escritorio (por ejemplo, a las 10:00 a.m.).
1b. Si el cambio de TZ está en una de las otras zonas de asistentes a la reunión, entonces no hay cambio

Consecuencias: se mueve para todos los demás, inesperadamente, debido a los propietarios cambio TZ, pero se mantiene "la reunión de las 10am" en lo que respecta al propietario.

''2. Como arriba, pero invertido.

Consecuencias: se mueve para el propietario de la reunión (la reunión de las 10am se convierte en la reunión de las 9am, o v / v), lo que puede esperarse pero es inconveniente. Permanece en el mismo tiempo de reloj de escritorio para los demás asistentes hasta que pasan por su propia transición TZ.

Ninguno de los dos es perfecto. Considere el caso de dos citas, una reservada por la persona A que ocurre a las 10 a.m. hora local, la otra reservada por la persona B con la persona A como asistente que ocurre a las 9 a. M. Si la persona A y la persona B se encuentran en diferentes TZ, un cambio en el horario de verano podría hacer que se dupliquen.

Si tu mente está un poco inclinada en este punto, entonces lo entiendo muy bien.

El punto detrás de este ejemplo es que para hacer cualquiera de estos comportamientos correctamente, usted necesita saber no solo la versión UTC de la hora local, sino la TZ (y no la compensación) en la que se encontraba el propietario cuando la reservaron. De lo contrario, no tiene más remedio que tomar la opción 2, en silencio, sin siquiera informar a nadie que las cosas han cambiado ya que las horas GMT no cambian y solo cambia la presentación ... ¿verdad? (no, esta es la trampa, la presentación importa cuando su reunión de las 10am se mueve sola)

Tengo que dar crédito a mi colega y amigo Jason Pollock por esta idea. Lea su punto de vista aquí , y el seguimiento que trata sobre iCal y VTIMEZONE aquí.

Tiene que almacenar en UTC; si no lo hace, su informe histórico y su comportamiento durante cosas como Horario de verano ... es divertido. GMT es una hora local, sujeta a Horario de verano relativo a UTC (que no es).

La presentación a los usuarios en diferentes zonas horarias puede ser un verdadero bastardo si está almacenando la hora local. Es fácil ajustarse a lo local si sus datos brutos están en UTC: simplemente agregue el desplazamiento de su usuario y ¡listo!

Joel habló de esto en uno de los podcasts (en forma redonda), dijo que almacenara sus datos en la resolución más alta posible (busque "fidelidad"), porque siempre puede enviarlos cuando se apaga nuevamente. Es por eso que digo almacenarlo como UTC, como la hora local que necesita ajustar para cualquiera que no esté en esa zona horaria, y eso es mucho trabajo duro. Y necesita almacenar si, por ejemplo, los ahorros de luz diurna entraron en vigencia cuando almacenó el tiempo. Yuk.

A menudo en las bases de datos en el pasado he almacenado dos: UTC para ordenar, hora local para mostrar. De esta forma, ni el usuario ni la computadora se confunden.

Ahora, como mostrar: seguro, puedes hacer lo de "hace 3 minutos", pero solo si almacenas UTC; de lo contrario, los datos ingresados en diferentes zonas horarias harán cosas como mostrar como "-4 horas atrás", lo que hará enloquece a la gente. Si va a mostrar una hora real, a las personas les encanta tenerla en su hora local, y si los datos se ingresan en varias zonas horarias, solo puede hacerlo con facilidad si está almacenando UTC.