Extend schedule handling cli support #501 has a list of timezones used by IOT & it implements support for setting the timezone, those could be cherry-picked to be a base for this
As we’ve persevered with py3.8 for so long I think we might as well stick out the next 3 months or so. However rather than installing the back port we could just check the python version in the cli / time module and warn / use utc respectively.
If we want to have support for timezoned datetimes throughout the library (e.g., to get on_since right for both iot and smart), we need to either use the version from backports or drop 3.8.
I'd actually go and drop it already, as that would make a clear cut when the first release of 0.7.0 already depends on the version that is not going to be completely unsupported (https://endoflife.date/python). Also, for pypy, 3.9 and 3.10 are already the only supported versions, so it'd nicely sync with that too.
On distributions, Debian is usually considered one of those that lag behind when it comes to new stuff, and their bullseye release, which already shipped 3.9, is also going to be EOL'd very soon. So I don't think we should keep on supporting obsoleted releases just for the sake of supporting them :-)
Activity
sdb9696 commented on Jun 15, 2024
As we’ve persevered with py3.8 for so long I think we might as well stick out the next 3 months or so. However rather than installing the back port we could just check the python version in the cli / time module and warn / use utc respectively.
rytilahti commented on Jun 15, 2024
If we want to have support for timezoned datetimes throughout the library (e.g., to get on_since right for both iot and smart), we need to either use the version from backports or drop 3.8.
I'd actually go and drop it already, as that would make a clear cut when the first release of 0.7.0 already depends on the version that is not going to be completely unsupported (https://endoflife.date/python). Also, for pypy, 3.9 and 3.10 are already the only supported versions, so it'd nicely sync with that too.
On distributions, Debian is usually considered one of those that lag behind when it comes to new stuff, and their bullseye release, which already shipped 3.9, is also going to be EOL'd very soon. So I don't think we should keep on supporting obsoleted releases just for the sake of supporting them :-)
sdb9696 commented on Jun 17, 2024
Ok fair enough, let's do it!
Drop python3.8 support (#992)
Drop python3.8 support (python-kasa#992)