Yes, it's related to -yy (which defaults to 1950). If the date falls outside of the 100-year window ranging from -yy to -yy + 99 (1950 to 2049) the century is included in the date so you know that it's not 1966, to use your example. For dates in the first century only one zero is used which is probably a bug but given that there aren't many practical uses for dates in the first century in OpenEdge applications it's not something we're likely to fix.

You have posted to a forum that requires a moderator to approve posts before they are publicly available.

We found this while testing our DB replication where the primary key contains a date field. We were storing the date in a char field with just STRING(date). We modified this to STRING(date,"99/99/9999") and we now get a valid date.

You have posted to a forum that requires a moderator to approve posts before they are publicly available.

And the outcome is 100% correct. It is not a matter of separator, it is a matter of datatype. When you pass in 01,26,66 you actually pass in 3 integers. When you pass in 01.26.66 or 01/26/66 you pass in a date.

Consider the possible ways to call the DATE function:

DATE ( month , day , year )

DATE ( string )

DATE ( integer-expression )

DATE ( datetime-expression )

when using DATE(1,26,66) you get (and should get!) 26 january of the year 66. Not 1966. If you wanted that you should have used DATE(1,2,6,1966) instead.

Funny though is that it is possible to notate a date with dots instead of slashes. Didn't know that.

You have posted to a forum that requires a moderator to approve posts before they are publicly available.