Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

daylight saving bug #608

Closed
bellt opened this issue Nov 23, 2023 · 3 comments · Fixed by #623
Closed

daylight saving bug #608

bellt opened this issue Nov 23, 2023 · 3 comments · Fixed by #623

Comments

@bellt
Copy link

bellt commented Nov 23, 2023

This is a re-open of #598
I schedule a daily job to run at a particular time in UTC. Most of the year the job runs at the correct local time corresponding to that time in UTC. However for approximately three weeks of the year an incorrect offset from UTC gets applied and the job runs at the wrong time. The weeks when the job runs at the incorrect time are:
a. One week after daylight saving comes into effect in my local timezone
b. Roughly two weeks before daylight saving ends in my local timezone.

Here are some tests to demonstrate this. The first two tests pass

with mock_datetime(2023, 9, 18, 10, 00, 0, TZ_AUCKLAND):
    # Testing timezone conversion the week before daylight saving comes into effect
    # Current time: Monday 18 September 10:00 NZST
    # Current time UTC: Sunday 17 September 22:00
    # Expected next run in NZST: 2023-09-18 11:00:00
    schedule.clear()
    next = schedule.every().day.at("23:00", "UTC").do(mock_job).next_run
    assert next.day == 18
    assert next.hour == 11
    assert next.minute == 0

with mock_datetime(2024, 4, 8, 10, 00, 0, TZ_AUCKLAND):
    # Testing timezone conversion the week after daylight saving ends
    # Current time: Monday 8 April 10:00 NZST
    # Current time UTC: Sunday 7 April 22:00
    # Expected next run in NZDT: 2023-04-08 11:00:00
    schedule.clear()
    next = schedule.every().day.at("23:00", "UTC").do(mock_job).next_run
    assert next.day == 8
    assert next.hour == 11
    assert next.minute == 0

And these next two tests fail

with mock_datetime(2023, 9, 25, 10, 00, 0, TZ_AUCKLAND):
    # Testing timezone conversion during the week after daylight saving comes into effect
    # Current time: Monday 25 September 10:00 NZDT
    # Current time UTC: Sunday 24 September 21:00
    # Expected next run in NZDT: 2023-09-25 12:00:00
    schedule.clear()
    next = schedule.every().day.at("23:00", "UTC").do(mock_job).next_run
    assert next.day == 25
    assert next.hour == 12 #FAIL
    assert next.minute == 0

with mock_datetime(2024, 4, 1, 10, 00, 0, TZ_AUCKLAND):
    # Testing timezone conversion during the week before daylight saving ends
    # Current time: Monday 1 April 10:00 NZDT
    # Current time UTC: Sunday 31 March 21:00
    # Expected next run in NZDT: 2024-04-01 12:00:00
    schedule.clear()
    next = schedule.every().day.at("23:00", "UTC").do(mock_job).next_run
    assert next.day == 1
    assert next.hour == 12 #FAIL
    assert next.minute == 0

If you'd like me to do a PR to include these tests then let me know.
@bellt
Copy link
Author

bellt commented Dec 3, 2023

It looked like the call to astimezone() on line 794 of __init__.py was returning the incorrect time in the failed tests. I was able to get all four of the above tests to pass by explicitly giving that method my local timezone like this

import pytz
# self.next_run = self.next_run.astimezone().replace(tzinfo=None)
self.next_run = self.next_run.astimezone(pytz.timezone('Pacific/Auckland')).replace(tzinfo=None)

However I haven't been able to find a clean way get the users local timezone and pass that in, so I can't run the other tests. Hence I'm not sure if this is the root source of the issue or if it is a red herring.

@SijmenHuizenga
Copy link
Collaborator

I know it has been ages since you submitted this... I'm now trying to solve the timezone bugs and your unit tests are tremendously helpful. Thank you.

After a lot of debugging i found that the definition of Auckland in the unit tests are wrong... Somehow it was set to change winter- to summertime in October instead of september 😭

-- TZ_AUCKLAND = "NZST-12NZDT-13,M10.1.0/02:00:00,M3.3.0/03:00:00"
++ TZ_AUCKLAND = "NZST-12NZDT,M9.5.0,M4.1.0/3"

That doesn't resolve the cross-timezone scheduling bug, but it's a start to figure out what is going on.

@bellt
Copy link
Author

bellt commented Apr 28, 2024

Oh whoops!

I can confirm that when we changed from daylight saving time to standard time earlier in April, my UTC-scheduled jobs started running an hour earlier one week before daylight saving ended.

@SijmenHuizenga SijmenHuizenga mentioned this issue May 4, 2024
Merged
7 tasks
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

Successfully merging a pull request may close this issue.

Timezone bugfixes SijmenHuizenga/schedule
2 participants
@bellt @SijmenHuizenga