Fix crash when parsing date

[snan]

I was getting a ValueError: Invalid isoformat string: '2023-09-23T13:07:50' crash.

[snan]

Dangit, I didn't realize dateutils wasn't part of the standard library 🤦🏻‍♀️

[danschwarz]

Thanks for the PR. Can you fix this without introducing a new library dependency? The datetime string you posted, 2023-09-23T13:07:50, looks correct to me - what's going on with the existing code?

[snan]

Thanks for the PR. Can you fix this without introducing a new library dependency? The datetime string you posted, 2023-09-23T13:07:50, looks correct to me - what's going on with the existing code?

When running toot notifications -rm on master, it crashes with this error message:

ValueError: Invalid isoformat string: '2023-09-23T13:07:50'

I can verify that it does by running python3 as a REPL and pasting in:

from datetime import date, datetime
date.fromisoformat('2023-09-23T13:07:50')

That crashes with the same error message for me. I then found this StackExchange thread which is what suggested dateutil 🤷🏻‍♀️

[snan]

I'm on Debian GNU/Linux 12 (bookworm). The Debian stable version of toot (which is 0.34) doesn't have this issue but I downloaded the git master version to work on an unrelated issue and then I ran into this.

According to that aforementioned thread support for this was added in version 3.11 so people on that version won't be able to replicate the bug. Still a problem for me though 🤷🏻‍♀️

[danschwarz]

OK thanks for the explanation, seems reasonable to me to add python-dateutil as we have a lot of date parsing that we need to get right. Hopefully @ihabunek will be back soon to weigh in on this. Meanwhile, if you can fix up the imports so the automated tests pass, I think this PR will be acccepted.

[snan]

Not sure how to do that 💁🏻‍♀️

[danschwarz]

Here's a fix that avoids the python-dateutil dependency:

rather than calling:
date.fromisoformat('2023-09-23T13:07:50')
call:
datetime.fromisoformat('2023-09-23T13:07:50')
then convert the datetime back to a date with datetime.date()

And, for good measure, convert any "Z" suffix (if it exists) to +00:00 as per this thread

Running with python3 (I'm running 3.10, which doesn't have the 3.11 improvements to fromisoformat)

>>> datetime.fromisoformat('2023-09-23T13:07:50'.replace('Z', '+00:00')).date()
datetime.date(2023, 9, 23)

Python-dateutil is more robust, but this should work for us, and we can always change later if necessary. And the above code change should pass the automated tests.

[snan]

datetime.fromisoformat('2023-09-23T13:07:50')

I can verify that that doesn't crash ♥♥👍🏻👍🏻

[danschwarz]

More interesting things...

#399 notes a documentation discrepancy in Mastodon regarding this field, and the toot crash

re: "controversial timezone workaround" - this was controversial at the time, but it seems that those who wanted to expand datetime.fromisoformat functionality won the argument, and starting in Python 3.11, it handles more variations of ISO 8601 datetime formats. 🤷‍♂️

Alternately, we could just use datetime.strptime as the datetime handling code a few lines above does, and forget about datetime.fromisoformat entirely 😬

datetime.strptime(value[:10], '%Y-%m-%d').date()

By the way - There was no test case exercising this code path in entities.py; to fix that we can update test_console.py with added last_status_at fields in two formats: ISO 8601 date, and ISO 8601 timestamp. So this should cover the two variations we know of right now.

Here's a patch file that adds the fields to the test cases. If you would git patch your branch with this file and push the changes to the PR, I'd appreciate it.

tc.patch

[snan]

Thank you for sending a patch 👍🏻 (instead of a PR on my branch 😵‍💫)