1. Important: Some other date fields *seem* to behave differently, but I
have no time to dig into it. (see below for different behaviour of
expire vs. create field) Is there some date calculation made before the
date is saved/written?
2. I try to enter the date Jan 31, 1998 in DMY format in the (ma)EXPIRE
field:
Date entered Date saved/redisplayed
31.01.98 16.04.49
31.01.1998 '13:types
incompatible'
31/01/1998 31.01.98 (OK)
31/01/98 31.01.98
(OK)
31.1.98 (omitting the '0') 31.05.85
1.31.98 (incorrect format, not DMY) 18.02.36 (should give
error!)
1/31/98 (incorrect format, not DMY) 31.01.98 (interesting:
although the result is correct, this entry MUST give an
error!!!!!!!!!!!!!!!!!!!!!!! A program should make no assumptions, but
check for validity and ASK if incorrect/misleading data is entered! )
3. I try to enter the date Jan 31, 1998 in DMY format in the (ma)CREATE
field:
Date entered Date saved/redisplayed
31.01.98 31.01.98 (OK)
31.01.1998 31.01.98 (OK)
31/01/1998 31.01.98 (OK)
31/01/98 31.01.98
(OK)
31.1.98 (omitting the '0') 31.01.98 (OK)
BUT: 31.2.98 (non-existing date) 08.09.85
(??????????????)
1.31.98 (incorrect format, not DMY) 31.01.98 (correct result,
but should give error!)
1/31/98 (incorrect format, not DMY) 31.01.98 ( see above)
Sorry, but IMHO the complete date validation/conversion routine needs a
rework......
How can we rely on the program when it comes to *internal* date
calculations?
****Is there anybody else on this list using Emerald with DMY or other
non-US dates?****
cu,
Peter