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