Re: how to handle date comparison

On 11-Aug-2016 08:58 -0500, MichaelQuigley wrote:

It is really very simple and easy. Here's the code excerpts:

---------------------------------

Working-storage.
01 Today format date '@Y%m%d'.

Procedure Division.

move function current-date to Today.
if Cust-add-date = Today
. . .
. . .
. . .

---------------------------------

You have to specify the format date as YYYYMMDD (using the
'@Y%m%d' format string) because that's how the current-date function
will provide it. Once you have the data in a true date field, the
compiler handles the comparison for you. Internally the dates are
stored as a Scaliger or Julian day number. That's an integer using a
system Joseph Scaliger formalized counting the days since an epoch.
The system converts the dates for you anytime you need to see the
value.

Yes, but …

To ensure the actual comparison is done with those internal date values requires the field be generated\loaded into the program as the DATE data-type rather than as ordinary CHAR; i.e. the above code, to function properly, requires that the Conversion Options (CVTOPT) had included the *DATE specification to signify to the compiler that "date data types are [to be] declared as category date COBOL data items".

For the scenario presented by the OP, the field Cust_add_date was defined as DDS-data-type-L [aka DATE] with the attribute of DATFMT(*MDY) [and presumed as defaulted DATSEP('/'); without that CVTOPT(*DATE) specified on the compile, the comparison would not actually be performed against those internal values, because that field would have been declared as a CHAR(8) to include separators so formatted as 'MM/DD/YY' [seen as PIC X(8). in the compiler listing] instead of declared as a DATE for which formatting is immaterial [seen as FORMAT DATE '%m/%d/%y' in the compiler listing].

I do not claim to know what comparison is effected during run-time when the database field is loaded as character, but I would guess the comparison performed would be of the formatted *MDY string data against the un-edited\de-edited string value for the DATE variable\data-item. I do know that they will mis-compare; perhaps per '08/11/16'<>'20160811'.?