Incorrect cron calculation in croniter when DST changed

[kkujawinski]

Croniter incorrectly calculate next cron hit if DST change occurs.

The reason is giving dateutil.tz.tzlocal object in initial datetime. You can read criticsm about here http://www.assert.cc/2014/05/25/which-python-time-zone-library.html.

I have already fixed this issue and I added proper test case.

Env: Ubuntu 14.04

[gawel]

Isn't that more related to https://github.com/kiorky/croniter ?

[gawel]

Oh no, didn't look at your patch. Nice one.

[kkujawinski]

IMO it is more related to dateutil.tz.tzlocal. Check the article I've pasted.

[st31ny]

I noticed today in the morning that after the DST change tonight aiocron fired at the wrong times, and continued to do so. This issue is still open, although #8 has been merged, so I wonder if the behaviour I observed is a new issue, or if this one has not been fully fixed yet.

I am using aiocron version 1.3 on python 3.5 with dateutil version 2.5.3.

[st31ny]

I did some tests with a small test script and noticed a very interesting behaviour:

$ faketime '2020-03-29 1:58:55' ./aiocron-test.py                                                                                                                    
start running at: 2020-03-29T01:58:55.439818+01:00
fired 59 1 * * * 59 at 2020-03-29T01:59:59.024419+01:00
fired 0 2 * * * at 2020-03-29T03:00:00.002449+02:00

$ faketime '2020-03-29 1:59:55' ./aiocron-test.py                                                                                                                    
start running at: 2020-03-29T01:59:55.687915+01:00
fired 59 1 * * * 59 at 2020-03-29T01:59:59.003210+01:00
fired 0 3 * * * at 2020-03-29T03:00:00.002315+02:00

Notice how a different job fires whether I start at 1:59:55 or 1:58:55.
I could reproduce that on two machines with different versions:

• Python 3.5.3, dateutil 2.5.3, tzlocal 1.3, aiocron 1.3, croniter 0.3.12
• Python 3.7.5, dateutil 2.7.3, tzlocal 2.1, aiocron 1.3, croniter 0.3.30

Both machines are set to CEST.

EDIT: This however is inconsistent with what I saw tonight at a production machine (first machine above) where jobs kept on being run at the wrong time.

EDIT2: If I think about it more thoroughly, it actually is consistent with what I have observed before. If I start the application early enough, only the job at 2 is executed but the job at 3 not. If I add more jobs at 02:01 and 03:01, only the job scheduled at 02:01 is executed but not the one at 03:01.

[gawel]

It the last time that this may occurs AFAIK. We'll never change again (at least in UE)

[Pigueiras]

We've just hit this today 😭 . Wasn't this fixed by: taichino/croniter#135? With croniter==1.0.15 also happens.

[gawel]

Looks like it was'nt. Just like UE laws :D

I really don't want to dig into this since those hour changes should disappear at some point... Next year?

Of course I'll be happy if someone provide a PR if the problem come from aiocron

[st31ny]

I really don't want to dig into this since those hour changes should disappear at some point... Next year?
That's what I'm looking for, too. Until then, I just have a reminder in my calendar to restart things after the DST change…

[thehcma]

Indeed, this also hit us (just for fun, tasks schedule on the minute, simply went haywire flooding the logging system with nonsense) - it's unfortunate we don't have a fix as, beyond the EU, many other countries still suffer from the (useless) DST disease.

[gawel]

Looks like DST will no longer change after November 2023 ?

[st31ny]

The bug still exists in version 1.8 is persistent even after multiple runs. So, my cron job is scheduled at 7:15 but since the DST change it was executed twice at 8:15… Probably, I'll have to restart the service.

[st31ny]

Apparently, it's still a bug in croniter: corpusops/croniter#91

[st31ny]

As a workaround, set the timezone explicitly using pytz.

[st31ny]

Hey, I just experimented with cronsim and found it quite promising as alternative for croniter that gets the DST transition right. Maybe this is worth a look: #39 .