Update story_list() to handle indexed_date values with or without microseconds

[NullPxl]

In reference to #88, this PR sets up a try/except block to include the maximum available resolution of a given timestamp in indexed_date rather than truncating data that comes after the seconds.

[rahulbot]

Looks good to me. Very pythonic.

[philbudne]

I'm pretty sure datetime.datetime.fromisoformat accepts both with and without microseconds BUT it expects EXACTLY six digits of fractional second!

>> import datetime as dt >> dt.datetime.fromisoformat("2024-01-02 03:04:05")

datetime.datetime(2024, 1, 2, 3, 4, 5)

>> dt.datetime.fromisoformat("2024-01-02 03:04:05.123456")

datetime.datetime(2024, 1, 2, 3, 4, 5, 123456)

>> dt.datetime.fromisoformat("2024-01-02 03:04:05.12345")

Traceback (most recent call last): File "<stdin>", line 1, in <module> ValueError: Invalid isoformat string: '2024-01-02 03:04:05.12345'

[NullPxl]

Oh wow nice catch @philbudne ! I didn't realize fromisoformat() did that. Do you think there's any chance of ever receiving something other than 0 or 6 digits of a fractional second? If so I'll stick with the try/except but otherwise fromisoformat() is cleaner.

[philbudne]

I don't know the code path in this case, BUT story-indexer uses datetime.isoformat() throughout to format datetimes. And it looks like "fromisoformat" accepts three digits (ms) of fractional second, as well as six, since fromisoformat's docstring says: "Construct a time from the output of isoformat()." And the isoformat docstring says: | isoformat(...) | [sep] -> string in ISO 8601 format, YYYY-MM-DDT[HH[:MM[:SS[.mmm[uuu]]]]][+HH:MM]. | sep is used to separate the year from the time, and defaults to 'T'. | The optional argument timespec specifies the number of additional terms | of the time to include. Valid options are 'auto', 'hours', 'minutes', | 'seconds', 'milliseconds' and 'microseconds'. And looking at /usr/lib/python3.10/datetime.py, I see: def _parse_hh_mm_ss_ff(tstr): # Parses things of the form HH[:MM[:SS[.fff[fff]]]] len_str = len(tstr) which is called by _parse_isoformat_time which is called by datetime.fromisoformat So, in my opinion, "fromisoformat" should be a safe and clean solution. The only reason this bit of minutia came to my attention is that I JUST had to deal with reading date/time strings from a CSV dumped by PostgreSQL, and it seems like psql truncates all trailing zeroes (and the dot), which is NOT acceptable to fromisoformat.

[NullPxl]

sounds good I like the suggestion, added it to the most recent commit

[rahulbot]

Great knowledge sharing. I like simple solutions 👍🏽