DATE function

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. 

[mention:9e4ee96fac634b8f91b580e1fb4f7e71:e9ed411860ed4f2ba0265705b8793d05] - 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

Code

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.

Result:

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:

• 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. 

I agree with @Patrick [mention:e666fffb14004b29b4bad87b731999a8:e9ed411860ed4f2ba0265705b8793d05]  in that this is expected.

My reason is as follows:

In the case of DATE( month, day, year) you are not working with a date, but with three integers. The third integer must be used as is, otherwise there will be no way to use that format to obtain a date in the first century.

-yy applies only to dates REPRESENTED without a century and has most likely started out as a method to simplify data capturing by allowing for the omission of the century.

If the system did not work as it is now, the following code would malfunction.

DEF VAR dd  AS INT  NO-UNDO.
DEF VAR mm  AS INT  NO-UNDO.
DEF VAR yy  AS INT  NO-UNDO.
DEF VAR dte AS DATE NO-UNDO. 

ASSIGN
  dte = 01/26/066
  dd  = DAY(dte)
  mm  = MONTH(dte)
  yy  = YEAR(dte)
  .

MESSAGE DATE(mm, dd, yy) VIEW-AS ALERT-BOX.

As it is today, the DATE function would bring us back to the original date, regardless of the century of the date.

I would expect the year to be 66 just not 066.

> I would expect the year to be 66 just not 066.

Your expectation is correct: YEAR(DATE (01,26,66)) returns 66.

But 66 AD can't be displayed using "99/99/99":

STRING(DATE (01,26,66), "99/99/99")

** Value 26/01/066 cannot be displayed using 99/99/99. (74)

The same case as DATE (01,26,10066). It will not be displayed as 01/26/66.

Both years are out of the 100‑year period specified by the -yy.

But try this:

SESSION:YEAR-OFFSET = 0.
MESSAGE DATE(01,26,66) VIEW-AS ALERT-BOX.