Does anyone know why DATE (01,26,66) would return 01/26/066 instead of 01/26/66?
I must be missing something. Why would that produce a 3-digit year beginning with a 0?
If I use DATE ("01/26/66") it returns correctly 01/26/66.
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.
I realized that my answer doesn't make sense for your example. DATE(1, 26, 0066) would be displayed as "01/26/066" but DATE(1, 26, 66) shows as "01/26/66". Are you using a non-default value for -yy?
Wow, I was scratching my head with your prior answer.
I use the default -yy.
I even tried using SESSION:YEAR-OFFSET = 1950.
What is odd is the if you pass the string "01/26/66" to the DATE function it works just fine.
Are you testing this in the Procedure Editor with no startup parameters? What platform are you using?
First century has to be shown as 099 to avoid ambiguity with whatever century is defined by -yy..
When you convert to string -yy is already applied..
Windows with 32-bit and 64-bit doing same thing.
I tested in PDSOE as well as web client runtime.
What does MESSAGE SESSION:STARTUP-PARAMETERS show?
continuing ... and the 3rd parameter of the DATE is an integer and cannot care about -yy.
What control are you using to display the date (.NET control or ABL control)? Century setting for the Windows OS is typically different from Progress run-time setting.
ABL MESSAGE VIEW-AS ALERT-BOX.
I guess Havard says this is working correctly...
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.
I believe this is actually a problem. Just consider the below example and see how the conversion of date behaves when the separator changes.
Peter Judge - Do you know if someone can check the DATE function implementation and find why the results differ when the separator is ","
Note: Code executed https://abldojo.services.progress.com
DISP 'Separator is `,` =>'.
DISPLAY INT(DATE(01,26,66)) STRING(DATE(01,26,66)) DATE(01,26,66) FORMAT "99/99/9999" SKIP.
DISP 'Separator is `.` =>'.
DISPLAY INT(DATE(01.26.66)) STRING(DATE(01.26.66)) DATE(01.26.66) FORMAT "99/99/9999" SKIP.
DISP 'Separator is `/` =>'.
DISPLAY INT(DATE(01/26/66)) STRING(DATE(01/26/66)) DATE(01/26/66) FORMAT "99/99/9999" SKIP.
Separator is `,` => 1,745,191 26/01/06 26/01/0066
Separator is `.` => 2,439,153 26/01/66 26/01/1966
Separator is `/` => 2,439,153 26/01/66 26/01/1966
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:
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.