Handling WFDB header date and time problems

We should aim to prevent the creation of WFDB headers which aren't to specification (via the WFDB write functions). We should also provide clear messaging for errors related to already created WFDB headers (via he WFDB read functions).

Two sets of projects have had WFDB header issues related to base_date recently:

1. 2020 and 2021 Challenges. These projects used -'s instead of /'s in the base_date and the date was given before the base_time: https://github.com/MIT-LCP/wfdb-python/issues/351 . As mentioned in this issue, the WFDB tools were not used to create these files, so these errorneous headers shouldn't come as a surprise.
   Error message: HeaderSyntaxError: invalid syntax in record line
2. Cerebral projects. These projects had a year for the base_date and no time. This problem was initially noted in: https://github.com/MIT-LCP/wfdb-python/issues/307. More recently, another user sent an email about this issue.
   Error message: ValueError: time data '2006' does not match format '%d/%m/%Y' (ecg files in https://physionet.org/content/cerebral-perfusion-diabetes/1.0.0/)
   Error message: ValueError: unconverted data remains: 10 (ECG files in https://physionet.org/content/cded/1.0.0/)

It isn't clear how the WFDB files for 2. were created. There is some indication that MIT-LCP helped generate these files.

At the very least we should:

• Use validation checks to prevent the creation of WFDB files with these issues in our WFDB toolboxes.
• Catch these issues in all of our WFDB toolboxes and provide clear, consistent error messages.

Since we need to address multiple issues across 3 different toolboxes this issue may get messy. I will update this post to denote how updates to the Matlab and C toolboxes will be tracked once that is determined.

Finally, it would also be good if our wfdbcheck algorithm would catch these issues. This could prevent cases like those seen in the 2020, and 2021 challenges from getting through (i.e. even if a header is created outside of our toolboxes, we'd like to flag it if it isn't to specification).

Start by tracing the WFDB write and read functions that handle base_date and base_time, then inspect how wfdbcheck processes malformed headers. Compare the listed invalid formats and errors; done means validation prevents non-specification headers and read/check paths provide clear, consistent messages.