DATE function oddity

Keith G.

Member
I was doing some testing on date/time import and conversion functions we had written when I ran across a gotcha with the DATE function. It seems to be perfectly fine with non-numeric characters for the year portion of a date string, ignoring them completely and using whatever (leading) numeric are present. All of the following run with no errors:

MESSAGE DATE ("12/31/197x") VIEW-AS ALERT-BOX INFORMATION. /* year is assumed to be 197 */
MESSAGE DATE ("12/31/19xx") VIEW-AS ALERT-BOX INFORMATION. /* year is assumed to be 19 */
MESSAGE DATE ("12/31/1xxx") VIEW-AS ALERT-BOX INFORMATION. /* year is assumed to be 1 */
MESSAGE DATE ("12/31/wxyz") VIEW-AS ALERT-BOX INFORMATION. /* year is assumed to be the current year */
MESSAGE DATE ("12/31/x977") VIEW-AS ALERT-BOX INFORMATION. /* year is assumed to be the current year */


Just my fun fact for the day.
 

andre42

Member
Interesting. You are slightly mistaken, though - in the second example the year is 2019, in the third example it is 2001. The default format of mm/dd/yy probably mislead you.
My guess is that the same helper functions apply that are active in manual input, eg. you input just month and day in a fill-in and the current year is added when you leave the field, a year that is only input as one or two digits is expanded to 4 digits, and invalid characters are ignored (which doesn't happen in other conversion functions like integer() ).
I suppose a safer way would be to split the date yourself, convert the entries to integer yourself (thus catching invalid characters and optionally years with less than 4 digits) and then using date(12, 31, 1977).

My guess is that if you ask Progress to change this behavior they will say they can't because of compatibility.
 
Top