2nd post: date handling.....strange....very strange......(still a

Peter A. Sang ( (no email) )
Mon, 3 Aug 1998 19:58:07 +0200

Regarding to my previous post, I played a little with the
Edit/Billing/Expire field and found some strange effects:

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