agronholm / agronholm/apscheduler

Feature request: well-defined behaviour around DST thresholds

Abierto
#120 1 comentario 0 reacciones 0 asignados Ver en GitHub
enhancement
Lenguaje dominante
Python
Estrellas
7.6k
Forks
783
Merge medio
4 d 8 h
PR fusionados (30 d)
5

Descripción

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. :-)

Guía de contribución

Abrir la guía de contribución

Evaluación

Este issue todavía no se ha evaluado.

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.