|
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. Regards, Jim Langston D.BALE@handleman.com wrote: > > I'm spending way too much time on this. <g> I prompted the CVTDAT command: > > Help on FROMFMT: > *CYMD > The date has the century, year, month, day format, cyymmdd, > where c is 0 for years 1940 through 1999 and is 1 for years > 2000 through 2039. > > Help on TOFMT: > *CYMD > The date format is converted to the century, year, month, > day format, cyymmdd, where c is 0 for years 1940 through > 1999 and is 1 for years 2000 through 2071. If the year in > the current format is only 2 digits, c will be set to 0 for > years 40 through 99 and to 1 for years 00 through 39. > > It seems to me that the FROMFMT parameter should be able to handle the century > digit being 0 through 9 and the 2-digit year for *CYMD being 00 through 99. > But I just tested this, and IBM's documentation on the help is right on. > > Whatever. > > Dan Bale > IT - AS/400 > Handleman Company > 248-362-4400 Ext. 4952 > > -------------------------- Original Message -------------------------- > May 1, 1925 would be represented as 0250501 in CYYMMDD format. The C > value of 0 does cover all of 1900 to 1999, 1 2000 to 2099, etc. > > What's confusing you, I suspect, is that the combination of QCENTURY, > QYEAR, QMONTH, and QDAY represent what the current date of the system > is and the system (current release and all that) only supports an IPL > date ranging from August 24 1928 to July 6 2053. This limit on the > range of QDATE does not mean that CYYMMDD formats have the same limit. > > I want to stress that this does not mean that application dates cannot go > beyond 2053. Using 4-digit date formats applications can support dates from > year 0001 to year 9999 with no problem. > > Bruce > > > > >Hi Dan, > > > >I don't know the answer to your question, unless it's "You don't." > > > >I found those dates in the help for the QCENTURY system value. > > > >Regards, > >Peter Dow > >Dow Software Services, Inc. > >909 425-0194 voice > >909 425-0196 fax > > > >----- Original Message ----- > >From: <D.BALE@handleman.com> > >To: <RPG400-L@midrange.com> > >Sent: Thursday, November 30, 2000 6:14 AM > >Subject: Re: Y2.1K Compliance > > > > > >> >it currently depends on the setting of the QCENTURY system > >> >value, where 0 = 1928-1999 and 1 = 2000-2053. > >> > >> I haven't followed this thread closely and, fortunately, I work in a shop > >>that > >> started using 8-digit dates ten years ago. But the above quote caught my > >>eye. > >> How do you represent May 1, 1925 using CYYMMDD? May 1, 2054? Why > >>wouldn't a > >> century digit of 0 cover all the years 1900-1999? And so on? > >> > >> Dan Bale > >> IT - AS/400 > >> Handleman Company > >> 248-362-4400 Ext. 4952 > +--- > | 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 > +--- +--- | 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 +---
As an Amazon Associate we earn from qualifying purchases.
This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].
Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.