apscheduler icon indicating copy to clipboard operation
apscheduler copied to clipboard

Feature request: well-defined behaviour around DST thresholds

Open backbord opened this issue 9 years ago • 1 comments

I would love to have clearly defined and predictable behaviour w.r.t. daylight saving time.

Example for CronTrigger in rough pseudo-code

from pytz import utc
resolution = timedelta(seconds=1)

...

    def get_next_fire_time(self, previous_fire_time, now):
        dt = max(self.start_date, previous_fire_time, now).astimezone(utc)
        while dt <= self.end_date:
            if self.is_valid_fire_time(dt):
                return dt
            date += resolution

    def is_valid_fire_time(self, dt):
        dt = dt.astimezone(self.timezone)
        return dt is something that can be matched by the field expressions

As an example, consider a trigger to be executed at 2:30 CET. The above code states that if

  • hour 2-3 is "missing" on March 27th 2016 due to a switch from winter to summer time, the next fire time after fire time 2:30 CET on March 26th will be be 2:30 CET on March 28th (leaving out the missing hour) and if
  • the clock is set from 3 to back to 2 (hour 2-3 being repeated) on October 25th 2015 due to a switch from summer to winter time, we would have fire times 2015-10-24T02:30 summer time, then 2015-10-25T02:30 summer time, then 2015-10-25T02:30 winter time (the repeated hour), and then 2015-10-26T02:30 winter time.

This is not an urgent request, as I patched this in my fork of your apscheduler.

Before apscheduler, I used cron in UTC to execute each task in summer AND winter time and then exit the task if the CET time would not match what I expected (just like is_valid_fire_time in the pseudo code above). I will never go back to cron. Apscheduler is so much more elegant. :-)

backbord avatar Mar 30 '16 09:03 backbord

A fix exists in the cron-dst-fix branch and is awaiting the 4.0 release.

agronholm avatar Jan 06 '18 15:01 agronholm