Primero, reconozca que en la terminología moderna debe decir UTC en lugar de GMT. En su mayoría son equivalentes, excepto que UTC se define con mayor precisión. Reserva el término GMT para hacer referencia a la parte de la zona horaria del Reino Unido que está en vigor durante los meses de invierno con la diferencia UTC+0.
Ahora a tu pregunta. UTC no es necesariamente la mejor manera de almacenar todos los valores de fecha y hora. Funciona particularmente bien para pasado eventos, o para futuros absolutos eventos, pero no funciona tan bien para futuros eventos locales. eventos - especialmente futuros recurrentes eventos.
Escribí sobre esto en otra respuesta recientemente, y es uno de los pocos casos excepcionales en los que la hora local tiene más sentido que la UTC. El argumento principal es el "problema del despertador". Si configura su reloj de alarma para UTC, se despertará una hora antes o después el día de las transiciones de horario de verano. Esta es la razón por la que la mayoría de la gente configura sus despertadores según la hora local.
Por supuesto, no puede simplemente almacene una hora local si está trabajando con datos de todo el mundo. Debe almacenar algunas cosas diferentes:
- La hora local del evento recurrente, como "08:00"
- La zona horaria en la que se expresa la hora local, como "América/Nueva_York"
- El patrón de recurrencia, en cualquier formato que tenga sentido para su aplicación, como diario, quincenal o el tercer jueves del mes, etc.
- La siguiente inmediata Fecha y hora UTC equivalentes, lo mejor que pueda proyectarlas.
- Tal vez, pero no siempre, una lista de fechas y horas UTC de eventos futuros, proyectada en un período predefinido en el futuro (tal vez una semana, tal vez 6 meses, tal vez uno o dos años, según sus necesidades).
Para los dos últimos, comprenda que el equivalente UTC de cualquier fecha/hora local puede cambiar si el gobierno responsable de esa zona horaria decide cambiar algo. Dado que hay múltiples actualizaciones de la base de datos de zonas horarias cada año, querrá tener un plan para suscríbete a los anuncios de actualizaciones y actualice su base de datos de zonas horarias regularmente. Cada vez que actualice los datos de su zona horaria, deberá volver a calcular las horas equivalentes a UTC de todos los eventos futuros.
Tener los equivalentes UTC es importante si planea mostrar cualquier tipo de lista de eventos que abarque más de una zona horaria. Esos son los valores que consultará para crear esa lista.
Otro punto a considerar es que si un evento está programado para una hora local que ocurre durante una transición de respaldo de DST, deberá decidir si el evento ocurre en la primera instancia (generalmente) o en la segunda instancia (a veces), o ambos (rara vez), e incorpore en su aplicación un mecanismo para garantizar que el evento no se active dos veces a menos que usted lo desee.
Si estaba buscando una respuesta simple, lo siento, pero no hay una. Programar eventos futuros en distintas zonas horarias es una tarea complicada.
Enfoque alternativo
Algunas personas me han mostrado una técnica en la que hacen usan la hora UTC para la programación, es decir, eligen una fecha de inicio en la hora local, la convierten a UTC para almacenarla y también almacenan la identificación de la zona horaria. Luego, en tiempo de ejecución, aplican la zona horaria para convertir la hora UTC original a la hora local, luego usan esa hora local para calcular las otras recurrencias, como si fuera la que se almacenó originalmente como se indicó anteriormente.
Si bien esta técnica funcionará , los inconvenientes son:
-
Si hay una actualización de la zona horaria que cambia la hora local antes de que se ejecute la primera instancia, cancelará todo el programa. Esto se puede mitigar eligiendo un tiempo en el pasado para la "primera" instancia, de modo que la segunda instancia sea realmente la primera.
-
Si la hora es realmente una "hora flotante" que debe seguir al usuario (como en el reloj de alarma de un teléfono celular), aún tendrá que almacenar la información de la zona horaria para la zona en la que se creó originalmente, incluso si esa no es la zona en la que quieres correr.
-
Agrega complejidad adicional sin ningún beneficio. Reservaría esta técnica para situaciones en las que es posible que haya tenido un programador solo UTC en el que está tratando de adaptar el soporte de zona horaria.
