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.

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

Kingston.gov.uk appears to have changed date formats again #3224

Open
cmsj opened this issue Dec 17, 2024 · 6 comments · May be fixed by #3225
Open

Kingston.gov.uk appears to have changed date formats again #3224

cmsj opened this issue Dec 17, 2024 · 6 comments · May be fixed by #3225

Comments

@cmsj
Copy link

cmsj commented Dec 17, 2024

          @ilbarone87 I think they might have changed something again, I'm now seeing:
2024-12-16 09:47:12.097 ERROR (SyncWorker_8) [custom_components.waste_collection_schedule.waste_collection_schedule.source_shell] fetch failed for source The Royal Borough of Kingston Council:
Traceback (most recent call last):
  File "/config/custom_components/waste_collection_schedule/waste_collection_schedule/source_shell.py", line 158, in fetch
    entries: Iterable[Collection] = self._source.fetch()
                                    ~~~~~~~~~~~~~~~~~~^^
  File "/config/custom_components/waste_collection_schedule/waste_collection_schedule/source/kingston_gov_uk.py", line 79, in fetch
    date=datetime.strptime(
         ~~~~~~~~~~~~~~~~~^
        data["echo_refuse_next_date"], "%Y/%m/%d %H:%M:%S"
        ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
    ).date(),
    ^
  File "/usr/local/lib/python3.13/_strptime.py", line 573, in _strptime_datetime
    tt, fraction, gmtoff_fraction = _strptime(data_string, format)
                                    ~~~~~~~~~^^^^^^^^^^^^^^^^^^^^^
  File "/usr/local/lib/python3.13/_strptime.py", line 352, in _strptime
    raise ValueError("time data %r does not match format %r" %
                     (data_string, format))
ValueError: time data 'Friday 20 December' does not match format '%Y/%m/%d %H:%M:%S'

Originally posted by @cmsj in #3078 (comment)

@cmsj
Copy link
Author

cmsj commented Dec 17, 2024

I added some debugging (e.g. _LOGGER.warning(f"refuse: {data["echo_refuse_next_date"]}")) to each of the Collection() creations to print the date string being extracted, and it seems like there is data for each collection type:

2024-12-17 00:52:11.140 WARNING (SyncWorker_0) [waste_collection_schedule.source.kingston_gov_uk] refuse: Friday 20 December
2024-12-17 00:52:11.140 WARNING (SyncWorker_0) [waste_collection_schedule.source.kingston_gov_uk] food: Friday 20 December
2024-12-17 00:52:11.140 WARNING (SyncWorker_0) [waste_collection_schedule.source.kingston_gov_uk] papercard: Friday 20 December
2024-12-17 00:52:11.140 WARNING (SyncWorker_0) [waste_collection_schedule.source.kingston_gov_uk] mixed: Monday 30 December

There's nothing showing up in the calendar though.

@cmsj
Copy link
Author

cmsj commented Dec 17, 2024

@ilbarone87 I'm seeing the same thing you did here: #3078 (comment)

@cmsj
Copy link
Author

cmsj commented Dec 17, 2024

I think I see why:

>>> from datetime import datetime
>>> datetime.strptime("Friday 20 December", "%A %d %B")
<python-input-4>:1: DeprecationWarning: Parsing dates involving a day of month without a year specified is ambiguious
and fails to parse leap day. The default behavior will change in Python 3.15
to either always raise an exception or to use a different default year (TBD).
To avoid trouble, add a specific year to the input & format.
See https://github.com/python/cpython/issues/70647.
  datetime.strptime("Friday 20 December", "%A %d %B")
datetime.datetime(1900, 12, 20, 0, 0)
>>>

i.e. it's assuming the year is 1900, so likely the calendar is being populated, just 124 years ago.

This is going to suck, because these dates will cross a year boundary (e.g. we'll still be in 2024 when the data is referencing 2025 and we'll need to detect that and compensate)

@cmsj
Copy link
Author

cmsj commented Dec 17, 2024

Filed PR #3225

@ilbarone87
Copy link

Amazing work @cmsj thank you!

@the-jeffski
Copy link

Wonder if we are better having some try loop in case they revert again to a previous format?

@5ila5 5ila5 linked a pull request Dec 18, 2024 that will close this issue
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants