RE: Invalid dates in data transfer

["Dennis Lovelady" <iseries@xxxxxxxxxxxx>]

>    Of course those literals would both need to be '1940-01-01' to be
> in the one hundred year window; oops :-)
>
>    However that CASE would not handle a date overflow and could
> replace many valid dates.  Thus actually ensuring the transfer
> function uses a four-digit-year is still preferable.

No oops necessary, since the solution was presented only as a means of
getting around the limitations of Excel, which by the way were misstated.
The apparent lower limit for Excel dates is 1/1/1900.

> Replacing only the value '0001-01-01' would ensure that any dates
> outside of the valid window would still fail; i.e. continue to
> diagnose as an error, anything other than the *LOWVAL, which is
> probably better than possibly corrupting the dates by resetting
> a valid date to a consistent yet wrong date.

Umm... I think you'll find that the system has already validated any date
field (I mean if the DB knows that it's a date), and that nothing will fall
"outside the valid window," whatever that is.  I think you will also find
that there are no *LOWVAL dates in these fields.  I believe that if you
debug an RPG program that attempts to set a date to *LOVAL, it will actually
be set to 0001-01-01.

Dennis