Clarification: Neither EpiData Entry nor EpiData Analysis can have date fields with illegal dates. E.g. February 29th is only allowed in leap years.
Epi6 could save illegal dates and never controlled the data while reading for correct content.
From the beginning of EpiData all date fields were included as "true
dates", meaning that there cannot be a date value which does not exist in the past or future. (dates before year 1600 can give problems)
For EpiData Analysis this has given some users problems since it was difficult to see in which records the date problems were located if some dates were rejected. Also some old dates before year 1800 have not been accomodated fully in analysis, but this should be a minor problem, since we never or very rarely have data from that period. And if we do one could split the dates into day month and year parts as three variables, although this would remove the automatic validation of the content of the data.
I suggest that we look at the possibility of implementing:
c. That, if neither a. nor b. is an option, more detail about the 'invalid' dates (record number, variable name) is provided so that they can be edited.
since we cannot use an illegal date for anything. Analysis with incorrect dates makes no sense.
Once we find a workable principle for this the same technical principle and list can include also names of variables/fields, which will be in conflict with internal functions, e.g. year, date or tab.