There is already a suggested check in the spreadsheet (https://docs.google.com/spreadsheets/d/14r-74onIKdq2oUmn5U7itX5bfBkfJ16_BhaqTEaul74/) sticky row 82 for endDate not being in the future. This is different. I suggest comparing the range of dates in dataTables (of dateTime data type) to the asserted temporalCoverage calendarDate beginDate and endDate to warn if these are not congruent.
This check could get over complicated. A simplified scope might be to only apply this check when a single pair of beginDate and endDate are provided at the entity level, comparing to the union of all dataTables. Or only warn when a dataTable exceeds the range, not just does not fill the range of dates. In that case knb-lter-sbc.101.1 would not have been flagged.
There is already a suggested check in the spreadsheet (https://docs.google.com/spreadsheets/d/14r-74onIKdq2oUmn5U7itX5bfBkfJ16_BhaqTEaul74/) sticky row 82 for endDate not being in the future. This is different. I suggest comparing the range of dates in dataTables (of dateTime data type) to the asserted temporalCoverage calendarDate beginDate and endDate to warn if these are not congruent.
See for example https://portal.lternet.edu/nis/metadataviewer?packageid=knb-lter-sbc.101.1 has beginDate of 1884-03-23 where Margaret meant 1984-03-23. A warn would have caught that typo.
This check could get over complicated. A simplified scope might be to only apply this check when a single pair of beginDate and endDate are provided at the entity level, comparing to the union of all dataTables. Or only warn when a dataTable exceeds the range, not just does not fill the range of dates. In that case knb-lter-sbc.101.1 would not have been flagged.