fix: return unrecognized date strings unchanged in datefmt

[gaoflow]

What

datefmt() (edgar/display/formatting.py) crashes with AttributeError: 'str' object has no attribute 'strftime' whenever it is handed a date string that does not match one of its three hard-coded patterns (YYYYMMDD, YYYYMMDDHHMMSS, YYYY-MM-DD).

from edgar.display.formatting import datefmt
datefmt("2022/03/04", "%B %d, %Y")   # AttributeError
datefmt("2022-3-4", "%B %d, %Y")     # AttributeError (non-zero-padded)
datefmt("March 4, 2022")             # AttributeError
datefmt("")                          # AttributeError

The if isinstance(value, str) branch only reassigns value to a parsed datetime when a regex matches; otherwise value stays a str and falls through to value.strftime(fmt).

Why it matters

datefmt is display-only and is called in 14 places on filing-derived date strings that are not guaranteed to be in one of the three formats, including the 10-K / 10-Q / 40-F header tables (period_of_report, filing_date), entity former-name rows (former_name['from'] / ['to']), and SGML header rendering (date_of_change). A single oddly-formatted or empty date string there takes down the whole table render rather than just that field.

Fix

Return the unrecognized string unchanged instead of calling strftime on it, so the helper degrades gracefully. This keeps the function silent-failure-free (it returns the value it was given, never None) while matching the "useful behavior, not a crash" principle for display code.

Verification

TestDatefmt added to tests/test_to_context.py (the existing home of the edgar.display.formatting unit tests): the recognized formats and datetime objects still format correctly, and the five previously-crashing strings (2022/03/04, 2022-3-4, March 4, 2022, N/A, ``) now pass through unchanged. The five pass-through cases fail on main and pass with this change. `hatch run test-fast` for the file is green; `ruff check` is clean on the changed lines.

[dgunning]

Approving — real crash, correct minimal fix. Thanks @gaoflow.

Reproduced the AttributeError: 'str' object has no attribute 'strftime' on main for all five inputs (2022/03/04, 2022-3-4, March 4, 2022, N/A, ""). Returning the unrecognized string unchanged is the right graceful-degradation behavior for a display-only helper called in 14 header/former-name render sites.

Verified on the branch (with a working-tree import): pass-through strings return unchanged with no crash, and recognized formats (20220304, 2022-03-04) still format correctly. All 9 TestDatefmt cases pass; the 5 pass-through cases fail on main.