Dla przykładu używaj następującego wyrażenia cron: „0 0 14 1 *?”
-> Pożar pierwszego dnia każdego miesiąca o godzinie 14:00.

Użyłem Quartz CronScheduleBuilder do zbudowania expession, ale to nie ma znaczenia.

Moja lokalna strefa czasowa to UTC + 01: 00, a lato (w tym roku) rozpoczyna się 31.03.2013 2:00, gdzie czas jest dostosowywany do 3:00.

Kiedy zaplanuję nowe zadanie przy użyciu proponowanego wyzwalacza, powiedzmy 20.02.2013, Quartz poprawnie obliczy System.DateTimeOffset dla „NextFireTimeUtc” poprawnie:
DateTime: 01.03.2013 13:00:00 (jest to czas UTC, który jest godziną za lokalną strefą czasową)
LocalDateTime: 01.03.2013 14:00:00

Zadanie zostanie prawidłowo uruchomione o godzinie 14:00, jak określono.

Teraz, jeśli zaplanuję pracę 20.03.2013, „NextFireTimeUtc” spowoduje:
DateTime: 01.04.2013 13:00:00 (jest to czas UTC, który jest teraz dwie godziny za lokalną strefą czasową)
LocalDateTime: 01.04.201315:00:00

Zwróć uwagę, że wynikowy NextFireTimeUtc spada teraz w czasie lokalnego lata. W rezultacie LocalDateTime został „poprawiony” o dodatkową godzinę od czasu UTC. Powoduje to uruchomienie pracy o godzinie 15:00, co nie jest tym, czego chcę.

Oczekuję (oczywiście), że „14” w wyrażeniu cron powinno zawsze powodować wyzwalanie wyzwalacza o godzinie 14:00, nawet w okresie letnim.

Musi istnieć łatwy sposób radzenia sobie z tym zjawiskiem, prawdopodobnie brakuje mi czegoś koncepcyjnego. Jestem zdezorientowany.

EDYTOWAĆ:
Problem polega na tym, że Quartz obliczapierwszy NextFireTimeUtc w zależności odobecny informacje o strefie czasowej. Aby to przetestować, zaplanowałem dwa różne wyzwalacze cron i wywołałem GetFireTimeAfter () na wyzwalaczu z rosnącym przesunięciem, aby wyświetlić wynikowe czasy pożaru w ciągu roku.

Wyzwalacz 1: strzelaj 28 dnia każdego miesiąca o godzinie 14:00

GetFireTimeAfter teraz + 00 miesięcy: 28.03.201313:00:00 +00: 00 <- to prawda
GetFireTimeAfter teraz + 01 miesięcy: 28.04.2013 12:00:00 +00: 00
GetFireTimeAfter teraz + 02 miesiące: 28.05.2013 12:00:00 +00: 00
GetFireTimeAfter teraz + 03 miesięcy: 28.06.2013 12:00:00 +00: 00
GetFireTimeAfter teraz + 04 miesięcy: 28.07.2013 12:00:00 +00: 00
GetFireTimeAfter teraz + 05 miesięcy: 28.08.2013 12:00:00 +00: 00
GetFireTimeAfter teraz + 06 miesięcy: 28.09.2013 12:00:00 +00: 00
GetFireTimeAfter teraz + 07 miesięcy: 28.10.2013 13:00:00 +00: 00 <- lato już się skończyło
GetFireTimeAfter teraz + 08 miesięcy: 28.11.2013 13:00:00 +00: 00

Pierwszy czas pożaru jest prawidłowy, ponieważ wciąż pada na czas zimowy. Czasy w „okresie letnim” są wyłączone o dodatkowe -1, co powoduje poprawny czas pożaru po dodaniu lokalnej strefy czasowej +2.

Wyzwalacz 1: strzelaj pierwszego dnia każdego miesiąca o godzinie 14:00

GetFireTimeAfter teraz + 00 miesięcy: 01.04.201313:00:00 +00: 00 <- to źle?
GetFireTimeAfter teraz + 01 miesięcy: 01.05.2013 12:00:00 +00: 00
GetFireTimeAfter teraz + 02 miesiące: 01.06.2013 12:00:00 +00: 00
GetFireTimeAfter teraz + 03 miesięcy: 01.07.2013 12:00:00 +00: 00
GetFireTimeAfter teraz + 04 miesięcy: 01.08.2013 12:00:00 +00: 00
GetFireTimeAfter teraz + 05 miesięcy: 01.09.2013 12:00:00 +00: 00
GetFireTimeAfter teraz + 06 miesięcy: 01.10.2013 12:00:00 +00: 00
GetFireTimeAfter teraz + 07 miesięcy: 01.11.2013 13:00:00 +00: 00 <- lato już się skończyło
GetFireTimeAfter teraz + 08 miesięcy: 01.12.2013 13:00:00 +00: 00

Pierwszy pożar spada już w okresie letnim, ale jest tylko przesunięty o -1, co powoduje lokalny czas wyzwalania o godzinie 15:00.

Tak więc wyzwalacz jest w porządku, z wyjątkiem pierwszego czasu aktywacji, jeśli zaplanowano go w okresie zimowym, a pierwsze wykonanie spadnie w okresie letnim. Jak sobie z tym poradzić?