Don't crash parsing ABF files with an invalid acquisition date

[h-mayorquin]

Some ABF files store a "no date" sentinel (all bits set) in their date header fields, and AxonRawIO currently raises while building the recording datetime from those values, which blocks reading the file entirely even though the date is non-essential annotation. Both the ABF v1 and ABF v2 paths produce out-of-range values from this sentinel, so parsing now falls back to a None recording datetime rather than failing, keeping the signal accessible.

[zm711]

Just one general question @h-mayorquin.

[zm711]

Interesting where did this come from?

[h-mayorquin]

this is a uv thing.

[h-mayorquin]

At the end:

For version 2 I replaced the try/except with an explicit check for the two "no date" sentinel values (0 and 0xFFFFFFFF) on uFileStartDate, falling back to rec_datetime = None only for those and letting any other out-of-range value raise as before.

For version 1 I did the equivalent, but on the time field rather than the date field. That path hardcodes the date to 1900 and only reads lFileStartTime, where 0xFFFFFFFF comes through as -1 and 0 is a legitimate midnight. So instead of matching the two literal values (which would wrongly reject a real midnight), I check that the value is a valid time-of-day (0 <= lFileStartTime < 86400). Same effect: the sentinel falls back to None, everything else builds normally, and there's no try/except.

Both are covered by a test asserting that invalid_date_abf1.abf and invalid_date_abf2.abf parse with rec_datetime = None.

[h-mayorquin]

This should be ready.

[zm711]

Good by me.