Arithmetic with date fields

Arithmetic operations that include a date field are restricted to adding a nondate to a date field, subtracting a nondate from a date field, and subtracting a date field from a compatible date field.

Date field operands are compatible if they have the same date format except for the year part, which can be windowed or expanded.

The following operations are not allowed:

  • Any operation between incompatible dates
  • Adding two date fields
  • Subtracting a date field from a nondate
  • Unary minus applied to a date field
  • Division, exponentiation, or multiplication of or by a date field
  • Arithmetic expressions that specify a year-last date field
  • Arithmetic statements that specify a year-last date field, except as a receiving data item when the sending field is a nondate

The sections below describe the result of using date fields in the supported addition and subtraction operations.

For more information about using date fields in arithmetic operations, see:

Usage notes

  • Arithmetic operations treat date fields as numeric items; they do not recognize any date-specific internal structure. For example, adding 1 to a windowed date field that contains the value 991231 (which might be used in an application to represent December 31, 1999) results in the value 991232, not 000101.
  • When used as operands in arithmetic expressions or arithmetic statements, windowed date fields are automatically expanded according to the century window specified by the YEARWINDOW compiler option..

Addition that involves date fields

The following table shows the result of using a date field with a compatible operand in an addition.

Table 1. Results of using date fields in addition
  Nondate second operand Date field second operand
Nondate first operand Nondate Date field
Date field first operand Date field Not allowed

For details on how a result is stored in a receiving field, see Storing arithmetic results that involve date fields.

Subtraction that involves date fields

This section describes the results of using date fields in subtraction.

The following table shows the result of using a date field with a compatible operand in the subtraction:

first operand - second operand

In a SUBTRACT statement, these operands appear in the reverse order:

SUBTRACT second operand FROM first operand

Table 2. Results of using date fields in subtraction
  Nondate second operand Date field second operand
Nondate first operand Nondate Not allowed
Date field first operand Date field Nondate

Storing arithmetic results that involve date fields

The ADD, COMPUTE, DIVIDE, MULTIPY, and SUBTRACT statements perform arithmetic, then store the result, or sending field, into one or more receiving fields.

In a MULTIPLY statement, only GIVING identifiers can be date fields. In a DIVIDE statement, only GIVING identifiers or the REMAINDER identifier can be date fields.

Any windowed date fields that are operands of the arithmetic expression or statement are treated as if they were expanded before use, as described under Semantics of windowed date fields.

If the sending field is a date field, then the receiving field must be a compatible date field. That is, both fields must have the same date format, except for the year part, which can be windowed or expanded.

If the ON SIZE ERROR clause is not specified on the statement, the store operation follows the existing COBOL rules for the statement and proceeds as if the receiving and sending fields (after any automatic expansion of windowed date field operands or result) were both nondates.

Table 3 shows how these statements store the value of a sending field in a receiving field, where either field can be a date field. The section uses the following terms to describe how the store is performed:

Nonwindowed
The statement performs the store with no special date-sensitive size error processing, as described under SIZE ERROR phrases.
Windowed with nondate sending field
The nondate sending field is treated as a windowed date field compatible with the windowed date receiving field, but with the year part representing the number of years since 1900. (This representation is similar to a windowed date field with a base year of 1900, except that the year part is not limited to a positive number of at most two digits.) The store proceeds as if this assumed year part of the sending field were expanded by adding 1900 to it.
Windowed with date sending field
The store proceeds as if all windowed date field operands had been expanded as necessary, so that the sending field is a compatible expanded date field.

Size error processing: For both kinds of sending field, if the assumed or actual year part of the sending field falls within the century window, the sending field is stored in the receiving field after removing the century component of the year part. That is, the low-order or rightmost two digits of the expanded year part are retained and the high-order or leftmost two digits are discarded.

If the year part does not fall within the century window, then the receiving field is unmodified, and the size error imperative statement is executed when any remaining arithmetic operations are complete.

For example:


77  DUE-DATE PICTURE 9(5) DATE FORMAT YYXXX.
77  IN-DATE  PICTURE 9(8) DATE FORMAT YYYYXXX VALUE 1995001.
    ...
    COMPUTE DUE-DATE = IN-DATE + 10000
      ON SIZE ERROR imperative-statement
    END-COMPUTE

The sending field is an expanded date field representing January 1, 2005. Assuming that 2005 falls within the century window, the value stored in DUE-DATE is 05001; that is, the sending value of 2005001 without the century component 20.

Table 3. Storing arithmetic results that involve date fields when ON SIZE ERROR is specified
  Nondate sending field Date field sending field
Nondate receiving field Nonwindowed Not allowed
Windowed date field receiving field Windowed Windowed
Expanded date field receiving field Nonwindowed Nonwindowed