Appdaemon breaks on a leapday

[eifinger]

2020-02-29 01:12:45.648713 WARNING AppDaemon: Traceback (most recent call last):
File "/usr/local/lib/python3.7/site-packages/appdaemon/scheduler.py", line 421, in loop
next_entries = self.get_next_entries()
File "/usr/local/lib/python3.7/site-packages/appdaemon/scheduler.py", line 335, in get_next_entries
next_exec = datetime.datetime.now(pytz.utc).replace(year=3000)
ValueError: day is out of range for month

Seems like the hardcoded year 3000 is not a leap day.

https://github.com/home-assistant/appdaemon/blob/e5888de13aa50c3805302132fbd7a157c431373d/appdaemon/scheduler.py#L344

[LordMike]

Seems python lacks an add-years function. This SO might provide one:

https://stackoverflow.com/a/15743908/1246988

There is also a .max value, e.g. datetime.datetime.max

[heydonms]

At a quick glance, it doesn't seem to need an exact date. I think it is just an arbitrary time that is far later than anyone will ever need to schedule an event. Assuming that is the case it can just use 3004 which is a leap year.

There may still be similar issues with leap seconds though, and those don't get defined until close to the time that they are inserted so it's not just a case of picking the correct future year. But at least that will only mess up scheduling for a second rather than a whole day.

[electrofloat]

Yes, it can be workaround-ed with just entering 3004 in that line instead of 3000. It's a "funny" bug nontheless :)

[benleb]

🤦‍♀️ docker quickfix: docker exec -it appdaemon sed -i 's/3000/2048/g' /usr/local/lib/python3.8/site-packages/appdaemon/scheduler.py && docker restart appdaemon appdaemon

[adandl]

🤦‍♀️ docker quickfix: docker exec -it appdaemon sed -i 's/3000/2048/g' /usr/local/lib/python3.8/site-packages/appdaemon/scheduler.py && docker restart appdaemon appdaemon

Hi - sorry for the question, but would you have a quickfix for installation on HassOS (aka hassio) as well?
Thanks!

[samnewman86]

I'm also on ha supervised, and I'm into the console for the correct container but can't cd to the correct directory

[grm]

🤦‍♀️ docker quickfix: docker exec -it appdaemon sed -i 's/3000/2048/g' /usr/local/lib/python3.8/site-packages/appdaemon/scheduler.py && docker restart appdaemon appdaemon

Works perfect for me !
Thanks

[adandl]

I'm also on ha supervised, and I'm into the console for the correct container but can't cd to the correct directo
Hi - how did you do that? @samnewman86 ?

[samnewman86]

I'm also on ha supervised, and I'm into the console for the correct container but can't cd to the correct directo
Hi - how did you do that? @samnewman86 ?

i used portainer and opened a console on the container.
i edited the file correctly, confirmed by copying it to my home directory and checking but the appdaemon log still shows the same error.
ive now tried rebooting the host and still no joy

[samnewman86]

The change has been rewritten over. what would do that?

[saaste]

I built a new raspberry pi docker image using the latest code from master. That removed the leapday error but I ended up having a new one that prevented container to start:

 AttributeError: module 'astral' has no attribute 'Location'

Ended up using tag 4.0.1 and the workaround by @benleb and now everything works fine.

[dlashua]

This has been fixed in the latest dev and master. There's another bug that leads to @saaste 's issue with master. It will be fixed shortly. However, editing requirements.txt to pin astral to version 1.10.1 should work.

astral==1.10.1

[docBliny]

Here's what I used on hassio:

docker exec -it addon_a0d7b954_appdaemon sed -i 's/3000/2048/g' /usr/lib/python3.8/site-packages/appdaemon/scheduler.py && docker restart addon_a0d7b954_appdaemon 

[acockburn]

Astral bug is now fixed in 4.0.3 (and was never a problem in dev)