Peter,
I get the same result. The problem also arises with a <yyyy/mm/dd> date field. The problem is worse with this format as illegal dates get stored in the .rec and then are unusable. This is a bug in the parsing of dates, as any date with extra digits in either part should be caught. I'll add an entry to the documentation system.
If you have a challenging data entry situation, you could separate day, month, year into three fields and apply the checks separately. Here is a way to do that. An invalid date is always caught, either by the individual ranges or by the date function under field2. Field1 and Field2 are created when the "first word" option is chosen for creating .rec files. Error checking during data entry can be turned off, but the error in coding dates will always show up and the user is forced to fix things (e.g. 29 02 2009)
dobs ##/##/#### (day, month, year) dob <dd/mm/yyyy> (confirm date)
dobs range 1 31 end
field1 range 1 12 end
field2 range 1900 2010 after entry dob = date(dobs,field1,field2) if (dob > today) then help "Date @dob is out of range" error clear dob goto dobs end
dob noenter end
Jamie Peter wrote:
typing "050820009" results in "05/08/2000", no check is triggered
typing "05/08/20009" results in "05/08/2000", no check is triggered
typing "5/8/20100" results in "05/08/20100" and triggers the check
typing "5/8/20009" results in "05/08/20009", no check is triggered
typing "5/8/20099" results in "05/08/20099", no check is triggered
typing "5/8/99999" results in "05/08/34463" and triggers the check
1, 2 and 3 are what I expected, but 4, 5 and 6 are not. I uninstalled and re-installed the program, but the problem remains.
Any suggestions? Is there a way to force the user to use 2 digits for days and months, for example?
thanks in advance, Peter.
epidata-list@lists.umanitoba.ca wrote:
I cannot reproduce this result. EpiData lets you enter extra digits if you do not enter the "/". When I try this, the extra digits get removed and the date goes through as though they were not entered.
Jamie
Peter wrote:
Dear all,
I'm just starting to use epidata entry so I have probably overlooked something. Any pointers are appreciated!
I defined a date field as follows in the .qes file:
DOB date of birth <dd/mm/yyyy>
in the .rec file I added the following sanity check:
DOB MUSTENTER AFTER ENTRY IF ((year(DOB) < 1900) OR (DOB > TODAY)) THEN HELP "This date is not allowed" TYPE=ERROR CLEAR DOB GOTO DOB ENDIF END END
Most of the time the field behaves as I expect it to: dates in the future or far in the past are not allowed. However, the following typo gets accepted without triggering an error: 05/08/20001. Adding an extra trailing zero (05/08/200010) results in a prompt conversion to 05/08/3402, and the sanity check works again. Some experimentation seems to confirm that values between 20000 and 20099 are accepted as valid for year, bigger values trigger either my check or are converted to some weird value, again triggering the check.
How can I prevent this from happening?
EpiData-list mailing list EpiData-list@lists.umanitoba.ca http://lists.umanitoba.ca/mailman/listinfo/epidata-list
EpiData-list mailing list EpiData-list@lists.umanitoba.ca http://lists.umanitoba.ca/mailman/listinfo/epidata-list