Programación y horario de verano

Question

Estoy escribiendo una aplicación de calendario/programación en PHP. En este momento tomo el día de la semana en que desea que ocurra el evento y el momento. También pido la zona horaria y la ajusto en consecuencia para obtener la hora del evento en GMT.

Luego almaceno ese tiempo como un desplazamiento desde la medianoche del día del espectáculo. Esto está bien y funciona bien, pero ¿qué sucede cuando alcanzo el horario de verano? No estoy seguro de qué hacer cuando eso suceda. El otro problema es que no todos los países tienen horario de verano, así que estoy en un aprieto.

Estoy mostrando estos eventos en un calendario, por lo que el tiempo es importante.

Answer 1

Lidiar con el horario de verano es un verdadero dolor.

Para eventos futuros, debe almacenar la ubicación y la hora local cuando se producirá el evento, no la hora GMT. Esto se debe a que a veces los gobiernos cambian cuando el horario de verano comienza y se detiene (sucedió el año pasado en los EE. UU.) Y los eventos cambian en GMT, pero no en la hora local.

Luego, si necesita notificar cuándo se produce el evento, todos los días recopile los eventos para las próximas 24-48 horas y luego convierta sus tiempos a GMT. Para hacer eso, necesita una base de datos de zona horaria de ubicación como this one. Obtenga el desplazamiento GMT para cada ubicación en el momento del evento y utilícelo para convertir la hora a GMT, luego sabrá exactamente cuándo ocurrirá el evento.

Answer 2

Creo que está en el camino correcto con GMT (UTC). Use UTC como su representación canónica de indicación de fecha y hora cada vez que tenga algún evento que ocurra (o haya ocurrido) en un momento específico en un punto en el tiempo. UTC no se ve afectado por las reglas de horario de verano, por lo que sirve como una gran representación de punto en el tiempo sin ambigüedades.

Una vez que tenga una estrategia para la representación inequívoca de la fecha/hora del evento, entonces se puede resolver muy fácilmente el problema de localizar fecha/horas basado en que zona horaria que tiene más sentido a aceptar de sus usuarios (o mostrarles) Probablemente también necesite conocer y almacenar la zona horaria del evento, pero, debido a que está almacenando la fecha/hora del evento real en UTC, puede ubicarlo fácilmente en la zona horaria del usuario si es más relevante. a ellos en cualquier caso de uso dado.

Esta localización generalmente se realiza con una biblioteca de zona horaria proporcionada por su SDK (por ejemplo, Java tiene java.util.Calendar) o como una extensión de terceros (por ejemplo, Python tiene pytz). Estoy seguro de que PHP tiene un equivalente, pero no estoy tan familiarizado con sus bibliotecas.

Estas bibliotecas generalmente se crean sobre una base de datos de reglas como Olson Zoneinfo DB. Estas reglas pueden cambiar con bastante frecuencia, por lo que debe estar al tanto de las actualizaciones de la base de datos subyacente, especialmente si está desarrollando una aplicación realmente global. Sin embargo, hacen un buen trabajo al externalizar las reglas de zona horaria esotéricas y nebulosas para que pueda (en teoría) actualizar la base de datos de reglas sin tener que realizar una actualización importante de su entorno de ejecución o realizar cambios de código significativos cuando las reglas DST en un cambio de área particular.

No es el problema más fácil del mundo y huele mal que tenemos que hacerlo, pero una vez que lo ha hecho un par de veces y asimila la separación de preocupaciones entre el almacenamiento exacto de la representación en un punto en el tiempo vs. de localización, entonces se convierte en segunda naturaleza.

Answer 3

Por qué no pasar la responsabilidad a los usuarios. Supongo que necesitan registrarse para poder usar la aplicación.

Solo dígales en su perfil cuál es su tiempo compensado.Como GMT + 2, GMT - 8, etc. Sabrían cuándo cambiaron sus ajustes de horario de verano y actualizaron su perfil en consecuencia.

Por supuesto, esto depende de su base de usuarios. Pueden aceptar el acercamiento o no.