MAINT: Be strict about EDF compatibility

In EDF+, for backwards compatibilty with EDF, the date must be in the range 01-01-1985 to 31-12-2084 inclusive.

The string "Startdate X X X X " in the recording field is valid in EDF+ but the short date notation at offset
0xA8 must always be present.

For anonymization purposes, the consensus is to use 01-01-1985 00:00:00.

By being tolerant/lenient you'll acomplish to stay friends with your userbase (at least in the short term),
but in the long term you'll hurt EDF(+) compatibility and ultimately the people who invested in EDF recording data bases.
It's better to disappoint them now (the people having trouble reading non-compliant files),
than to end up with a big pile of non-compliant files.

All non-compliant files that can still be accessed by being tolerant, can also be fixed by EDFbrowser.
If a non-compliant file can not be fixed by EDFbrowser, it can not be read (and have useful data) by being tolerant.
If you don't like the dependency to EDFbrowser for fixing non-compliant files, feel free to have a look at
the code and write your own EDF-fixer in Python.
That's how you help people and preserve the future of the EDF format at the same time.

Rationale: By refusing to open non-compliant files but offering a tool that modifies these files and fix them,
you make people aware of the problem but still give them a solution.
The advantage is that they will usually report back / complain to the person responsible for the non-compliant
files which is a good thing.

Originally posted by @Teuniz in https://github.com/mne-tools/mne-python/issues/11603#issuecomment-1488676849

The issue does not name repository files or tests. Start by locating the EDF/EDF+ header and date-validation entry points, then review how out-of-range dates and missing short-date notation are handled. Done means the stated EDF compatibility rules are enforced, including the anonymization date, with coverage for compliant and non-compliant files.