Y2.1K Compliance

The date values supported by CVTDAT, and the date values supported for
*DATE command parameters, are both based on only allowing valid job
dates to be entered/used.  As mentioned in an earlier note, OS/400
supports IPL dates from August 24 1928 to July 6 2053; well OS/400 also
support a slightly wider range for job dates, namely August 24 1928 to
May 9 2071 (and actually these ranges go a little into Aug 23 1928 and
May 10 2071 but we'll just use whole days for this discussion).  There
are implementation details that explain why this range that was covered
back in Y2K days.

Prior to the Y2K work of past releases, the range was from January 1 1940
to December 31 2039 for CVTDAT, *DATE, and for most practical purposes
job date.  With the Y2K work job date was expanded to the range given
above and it was decided to enhance CVTDAT and *DATE parameters in the
same way.  At that time a rather conservative approach was taken - namely
since CVTDAT and *DATE could only generate valid job dates (and no one
knew how many implicit assumptions in job streams there might be about
generated dates and the ability to later change a given job to that date)
prior to the Y2K work that they would continue to only support the valid
job date range.  In hind sight this was probably not the wisest decision;
and fortunately there is nothing to really stop OS/400 from expanding
on this range in the future (just like how 1940 to 2039 was expanded
for V3R2/V3R7).

As you point out, there are plenty of other interfaces that do not
have this range limitation (Date datatypes, ILE CEE routines, etc.)
that currently exists with *DATE command parameters and CVTDAT.

Bruce

>
>I pressed F1 on the CVTDAT command, then F2 for extended help and saw
>this additional information:
>
> Only valid dates can be converted.  If either the from-format or the
> to-format use only 2 digits to specify the year (for example, *MDY,
> *DMY, *YMD, or *JUL), valid dates are in the range of January 1,
> 1940, to December 31, 2039.  Otherwise, valid dates are in the range
> of August 24, 1928, to May 9, 2071.  If the year is specified with
> only 2 digits, years in the range of 40 to 99 are assumed to be 1940
> to 1999; years in the range 00 to 39 are assumed to be 2000 to 2039.
> The command works in conjunction with the QLEAPADJ system value.
>
>I do not know where the, seemingly artificial, date restriction of
>August 24, 1928 (19280824), to May 9, 2071 (20710509) comes from.
>Perhaps this has something to do with the way the CVTDAT command
>works internally?  Hmm.. perphaps it saves the date in the interm
>as number of days since 19280824 in an interger variable during
>conversion.  They probably picked that date from somethign having to
>do with leap years or some such other magic.  Which would put the
>date of 20710905 at the limit of the number of days they can store
>in whatever size interger they are using.
>
>Understand, this is all just guesswork.  You can do all this without
>having to use CVTDAT by just using native OS400 date variables in
>the first place.
>


+---
| This is the RPG/400 Mailing List!
| To submit a new message, send your mail to RPG400-L@midrange.com.
| To subscribe to this list send email to RPG400-L-SUB@midrange.com.
| To unsubscribe from this list send email to RPG400-L-UNSUB@midrange.com.
| Questions should be directed to the list owner/operator: david@midrange.com
+---