Moves involving date fields

If the sending item is specified as a year-last date field, then all receiving fields must also be year-last date fields with the same date format as the sending item. If a year-last date field is specified as a receiving item, then the sending item must be either a nondate or a year-last date field with the same date format as the receiving item. In both cases, the move is then performed as if all items were nondates.

Table 1 describes the behavior of moves involving non-year-last date fields. If the sending item is a date field, then the receiving item must be a compatible date field. If the sending and receiving items are both date fields, then they must be compatible; that is, they must have the same date format, except for the year part, which can be windowed or expanded.

This table uses the following terms to describe the moves:

Normal
The move is performed with no date-sensitive behavior, as if the sending and receiving items were both nondates.
Expanded
The windowed date field sending item is treated as if it were first converted to expanded form, as described under Semantics of windowed date fields.
Invalid
The move is not allowed.

Table 1. Moves involving date fields


Nondate receiving item Windowed date field receiving item Expanded date field receiving item
Nondate sending item Normal Normal Normal
Windowed date field sending item Invalid Normal Expanded
Expanded date field sending item Invalid Normal1 Normal
  1. A move from an expanded date field to a windowed date field is, in effect, a "windowed" move, because it truncates the century component of the expanded date field. If the move is alphanumeric, it treats the receiving windowed date field as if its data description specified JUSTIFIED RIGHT. This is true even if the receiving windowed date field is a group item, for which the JUSTIFIED clause cannot be specified.