ABF1: read 2-digit-year (YYMMDD) acquisition dates correctly

[h-mayorquin]

I found another bug @zm711

PR #1870 started reading the real acquisition date from lFileStartDate in ABF (Axon Binary Format) version 1 files, assuming that field is always packed as YYYYMMDD but older ABF version 1 files pack it as YYMMDD with a 2-digit year instead, so a file storing 180618 came back as year 18 rather than 2018-06-18. This handles both packings.

[zm711]

Just one question @h-mayorquin

[zm711]

How do we know this is true?

[h-mayorquin]

The assumption you mean?

[zm711]

Yeah exactly the assumption of only after 2000.

[h-mayorquin]

Thanks for making me check this. I was basing that on the heuristic that the ABF acquisition system came after this, but it seems there are recordings in the 90s so that goes out the window. The heuristic is wrong.

So I dropped the century assumption entirely and disambiguate with the one hard invariant we do have: a recording cannot be in the future. A 2-digit year is mapped to the 2000s, and only falls back to the 1900s if that would land past the current year:

if year_is_two_digit:
    year += 2000
    if year > datetime.datetime.now().year:
        year -= 100  # e.g. 98 -> 1998 rather than a not-yet-happened 2098

That gives:

• 180618 -> 2018-06-18 (the fixture; still passes)
• 980618 -> 1998-06-18 (a real 90s file now dates correctly instead of 2098)
• 20050611 -> 2005-06-11 (4-digit path unchanged)

Worth noting the 2-digit form is not a "this recording is old" signal: the test fixture is a 2018 recording that still emits YYMMDD, so it is a software/version quirk rather than an era marker. And since Axon didn't exist before the 1990s, every 2-digit year that can appear in a real file resolves unambiguously under this rule. Until we get to 2090 or something like that :P