[EpiData-list] date field: check fails

epidata-list at lists.umanitoba.ca epidata-list at lists.umanitoba.ca
Fri Aug 7 07:31:42 CDT 2009


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:
> 1. typing "050820009" results in "05/08/2000", no check is triggered
> 2. typing "05/08/20009" results in "05/08/2000", no check is triggered
> 3. typing "5/8/20100" results in "05/08/20100" and triggers the check
>
> 4. typing "5/8/20009" results in "05/08/20009", no check is triggered
> 5. typing "5/8/20099" results in "05/08/20099", no check is triggered
> 6. 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 at 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 at lists.umanitoba.ca
>> http://lists.umanitoba.ca/mailman/listinfo/epidata-list
>>
> _______________________________________________
> EpiData-list mailing list
> EpiData-list at lists.umanitoba.ca
> http://lists.umanitoba.ca/mailman/listinfo/epidata-list
>   



More information about the EpiData-list mailing list