Por ejemplo, usemos la siguiente expresión cron: "0 0 14 1 *?"
-> Incendio el 1er día de cada mes a las 14:00 horas.

Utilicé Quartz CronScheduleBuilder para construir la expesión, pero esto es irrelevante.

Mi zona horaria local es UTC + 01: 00 y el horario de verano (este año) comienza el 31.03.2013 2:00, donde la hora se ajusta a las 3:00.

Cuando programo un nuevo trabajo utilizando el activador propuesto, digamos 20.02.2013, Quartz calcula el System.DateTimeOffset para el "NextFireTimeUtc" correctamente para:
DateTime: 01.03.2013 13:00:00 (esta es la hora UTC, que es una hora detrás de la zona horaria local)
Fecha y hora local: 01.03.2013 14:00:00

El trabajo se activará correctamente a las 14:00 horas según lo especificado.

Ahora, si programo el trabajo el 20.03.2013, el resultado de "NextFireTimeUtc" será:
Fecha y hora: 01.04.2013 13:00:00 (esta es la hora UTC, que ahora está dos horas por detrás de la zona horaria local)
LocalDateTimeTime: 01.04.201315:00:00

Tenga en cuenta que el NextFireTimeUtc resultante ahora cae dentro del horario de verano local. Como resultado, LocalDateTime también se "corrigió" una hora adicional desde la UTC. Esto da como resultado que el trabajo se ejecute a las 15:00 horas, que no es lo que quiero.

Lo que (obviamente) esperaba es que el "14" en la expresión cron siempre debe dar como resultado que el disparador se active a las 14:00, incluso durante el verano.

Debe haber una manera fácil de lidiar con este fenómeno, probablemente me esté perdiendo algo conceptual. Estoy confundido.

EDITAR:
El problema parece ser que el cuarzo calcula laprimero NextFireTimeUtc dependiendo de lacorriente información de zona horaria. Para probar esto, programé dos activadores de cron diferentes y llamé a GetFireTimeAfter () en el activador con un desplazamiento creciente para ver los tiempos de disparo resultantes durante el año.

Disparador 1: Incendio el 28 de cada mes a las 14:00

GetFireTimeDespués de ahora + 00 meses: 28.03.201313:00:00 +00: 00 <- esto es correcto
GetFireTimeDespués ahora + 01 meses: 28.04.2013 12:00:00 +00: 00
GetFireTimeDespués ahora + 02 meses: 28.05.2013 12:00:00 +00: 00
GetFireTimeDespués ahora + 03 meses: 28.06.2013 12:00:00 +00: 00
GetFireTimeDespués de ahora + 04 meses: 28.07.2013 12:00:00 +00: 00
GetFireTimeDespués ahora + 05 meses: 28.08.2013 12:00:00 +00: 00
GetFireTimeDespués de ahora + 06 meses: 28.09.2013 12:00:00 +00: 00
GetFireTimeDespués de ahora + 07 meses: 28.10.2013 13:00:00 +00: 00 <- el horario de verano ya terminó
GetFireTimeDespués de ahora + 08 meses: 28.11.2013 13:00:00 +00: 00

El primer tiempo de disparo es correcto, ya que todavía cae en "invierno". Los tiempos durante el "horario de verano" están desactivados por un -1 adicional, lo que resulta en el tiempo de disparo correcto después de que la zona horaria local agregue +2.

Disparador 1: dispara el primer día de cada mes a las 14:00

GetFireTimeDespués de ahora + 00 meses: 01.04.201313:00:00 +00: 00 <- esto esta mal?
GetFireTimeDespués ahora + 01 meses: 01.05.2013 12:00:00 +00: 00
GetFireTimeDespués de ahora + 02 meses: 01.06.2013 12:00:00 +00: 00
GetFireTimeDespués ahora + 03 meses: 01.07.2013 12:00:00 +00: 00
GetFireTimeDespués ahora + 04 meses: 01.08.2013 12:00:00 +00: 00
GetFireTimeDespués ahora + 05 meses: 01.09.2013 12:00:00 +00: 00
GetFireTimeDespués de ahora + 06 meses: 01.10.2013 12:00:00 +00: 00
GetFireTimeDespués de ahora + 07 meses: 01.11.2013 13:00:00 +00: 00 <- el horario de verano ya terminó
GetFireTimeDespués de ahora + 08 meses: 01.12.2013 13:00:00 +00: 00

El primer incendio ya cae dentro del horario de verano, pero solo se compensa con -1, lo que resulta en un tiempo de activación local de 15:00.

Por lo tanto, el activador está bien, excepto por el primer tiempo de activación, si está programado durante el invierno y la primera ejecución cae dentro del verano. ¿Cómo manejar esto?