daylight saving bug about schedule HOT 3 CLOSED

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.

from schedule.

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.

from schedule.

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.

from schedule.