La programación adecuada de las tareas futuras por hora local, teniendo en cuenta las zonas horarias y el horario de verano, es un tema muy complejo. He escrito sobre esto antes desde una perspectiva de programación en Stack Overflow aquí y aquí .
Resumiré desde una perspectiva no programada:
Defina sus patrones de recurrencia por hora local , no UTC . Por ejemplo, si configura un despertador diario para que se despierte a las 8:00 a.m. todos los días, no desea despertarse una hora antes o una hora más tarde después de una transición de horario de verano. Si estoy en la zona horaria del Pacífico de EE. UU., No puedo programar para las 4:00 p.m. UTC, porque después de la transición tendría que cambiar a las 3:00 p.m. UTC para mantener la misma hora local a las 8:00 a.m.
Defina la zona horaria que representa la hora "local". No asuma que la zona horaria local del servidor es la misma zona horaria que le importa al usuario final.
Proyecte la hora local en una fecha y hora UTC para cada ocurrencia que desee que se active el evento.
Casi siempre lo hará para la próxima aparición inmediata, de modo que pueda usar el reloj UTC para determinar el instante real a tiempo para ejecutarse.
En algunos casos, es posible que desee proyectar también las próximas varias (o muchas) instancias, como las siguientes 5 ocurrencias, o todas las ocurrencias para el próximo año. (Esta parte es altamente específica para los requisitos de la aplicación).
Establezca una estrategia (ya sea fija o configurable) sobre qué hacer en caso de que ocurra en el momento de la transición del horario de verano :
Para la transición "hacia adelante", hay una brecha de tiempo local perdido cuando la ocurrencia podría no existir. Por ejemplo, en la hora del Pacífico de EE. UU., Una tarea diaria programada para ejecutarse a las 2:00 a.m., hora local, no existirá el 9 de marzo de 2014. En la mayoría de los casos, querrá adelantar esa hora por la cantidad de ahorro (generalmente 1 hora ), ese día se ejecutará a las 3:00 a.m., pero volverá a funcionar a las 2:00 a.m. en la próxima instancia. (Sin embargo, es muy posible que desee una estrategia diferente para esto).
Para la transición "retroceder", hay una superposición de hora local duplicada cuando la ocurrencia puede existir dos veces . Por ejemplo, en la hora del Pacífico de EE. UU., Una tarea diaria programada para ejecutarse a la 1:00 a.m. tendrá dos posibles horas a las que podría ejecutarse el 2 de noviembre de 2014. En la mayoría de los casos, querrá ejecutarse en la primera aparición de 1 : 00 AM PDT y omita la próxima aparición de 1:00 AM PST de la misma fecha. (Pero, de nuevo, es posible que desee una estrategia diferente, como ejecutarse en la segunda aparición o en ambas. YMMV)
Esté preparado para volver a calcular todos los tiempos UTC de ocurrencia si alguna vez necesita actualizar los datos de su zona horaria. La IANA / Olson TZDB publica múltiples actualizaciones cada año porque los gobiernos del mundo cambian de opinión todo el tiempo sobre sus compensaciones de zona horaria y las reglas de horario de verano. No puede asumir por un período de tiempo específico en el futuro que las reglas no cambiarán .
Asegúrese de suscribirse a los anuncios de lanzamientos de datos de zona horaria, y tenga un proceso para aplicarlos a sus sistemas y / o aplicaciones.
En un entorno corporativo tradicional, esto debería ser responsabilidad del personal de operaciones de TI.
Dependiendo de su entorno, puede obtener estos datos a través de tzdataactualizaciones de paquetes de Linux, a través de Java JRE o tzupdater , o cualquier otro número de canales. A veces es específico del entorno, y a veces es específico de la plataforma de programación, como el paquete timezonedb PECL para PHP , y muchos otros.
Microsoft tiene sus propios datos de zona horaria. En Windows, si está utilizando TimeZoneInfo.NET (por ejemplo), está utilizando estos datos. Las actualizaciones provienen de aquí , y también se envían automáticamente a través de Windows Update, por lo que debe estar atento a ellas para saber cuándo / si necesita recalcular.
Con todo esto entendido, no es todavía un escenario donde se programaría simplemente por UTC, y que es para ABSOLUTOS eventos futuros. Ejemplos:
Un trabajo que se ejecuta cada X horas o cada X minutos.
Hora de inicio y parada del amanecer, u otro fenómeno astronómico.
Una ventana de seguridad sensible al tiempo, como cuando se transmite información confidencial a otra parte en un momento previamente acordado.
Programador de tareas de Windows
Windows no necesariamente está haciendo lo correcto. Preste atención a cómo define el desencadenante:
Cuando marca la casilla "Sincronizar a través de zonas horarias", la tarea es programada solo por UTC. (Todas las horas todavía se muestran como hora local, pero se almacenan como UTC). Así que esto es para lo que antes llamé un evento "absoluto".
Cuando deje esa casilla sin marcar, usará la zona horaria local de la computadora en la que se ejecuta el código. No le da ninguna opción para especificar la zona horaria, por lo que no es una muy buena implementación en mi humilde opinión.
No estoy exactamente seguro de su comportamiento DST, pero experimentaré y te responderé al respecto. Probablemente hace lo que describí anteriormente, pero no necesariamente.
Agente SQL
El planificador del Agente SQL es aún peor, ya que solo le permite usar la hora del servidor local. Nuevamente, no se pueden especificar zonas horarias y tampoco se puede especificar UTC.
Ha sido solicitado , pero no aceptado.