2039 Year Limitation in CVTDATE

240 pts.
Tags:
AS/400
CVTDATE
I used date 20430923 to be converted to *ISO format using CVTDATE, but got a machine error. How do I overcome this limitation? Does iSeries provide another command to accomplish the same?

Software/Hardware used:
AS400 , I series

Answer Wiki

Thanks. We'll let you know when a new response is added.

The following program works fine for me on V5R4. What does your program look like and what release are you on?

                                  

Bruce Vining

Pgm
Dcl Var(&FromDate) Type(*Char) Len(8) +
Value(’20430923′)
Dcl Var(&ToDate) Type(*Char) Len(10)

CvtDat Date(&FromDate) ToVar(&ToDate) +
FromFmt(*YYMD) ToFmt(*ISO)
EndPgm

Discuss This Question: 14  Replies

 
There was an error processing your information. Please try again later.
Thanks. We'll let you know when a new response is added.
Send me notifications when members answer or reply to this question.

REGISTER or login:

Forgot Password?
By submitting you agree to receive email from TechTarget and its partners. If you reside outside of the United States, you consent to having your personal data transferred to and processed in the United States. Privacy
  • ToddN2000
    That's a good one... I think if it's a major issue they will come out with a PTF to resolve the issue. I cannot think of to many instances where anyone would be using a date beyond that point.. Brings up flash back to the old Y2K problem but we made it through that. For now you may just have to hard code a solution.
    9,975 pointsBadges:
    report
  • TomLiotta
    Are you asking about "CVTDATE" or is it CVTDAT"? I don't know what "CVTDATE" is, but "CVTDAT" is a native command that bvining shows in his example 'Answer". -- Tom
    125,585 pointsBadges:
    report
  • asakla
    Hi Bruce , I used PgmDcl Var(&FromDate) Type(*Char) Len(7) +Value(’1430923′)Dcl Var(&ToDate) Type(*Char) Len(10)CvtDat Date(&FromDate) ToVar(&ToDate) +FromFmt(*CYMD) ToFmt(*ISO)EndPgmand Got error , But now i changed it to ur format and it worked , Thanks :) ,But it does not work for the following PgmDcl Var(&FromDate) Type(*Char) Len(8) +Value(’20430923′)Dcl Var(&ToDate) Type(*Char) Len(10)CvtDat Date(&FromDate) ToVar(&ToDate) +FromFmt(*YYMD) ToFmt(*JULDAT)EndPgm
    240 pointsBadges:
    report
  • TomLiotta
    But it does not work for the following...   The *JUL date format cannot be used with years after 2039. Use the *LONGJUL format instead.   I suspect that your programming can't handle dates correctly. You can convert to *LONGJUL format, and then truncate the two century digits. When you do that, you will get an invalid/incorrect Julian date, but it can be stored, printed or displayed as a character value.   Tom
    125,585 pointsBadges:
    report
  • asakla
    Hi TOM , I tried the Long Julian it works But it also has a limitation beyong 2070 ...
    240 pointsBadges:
    report
  • TomLiotta
    Then truncate the century digits from &FROMDATE. If you don't want to use 4-digit years, then don't use them. Go back to using *JUL for the output date format, and stop trying to input 4-digit years. -- Tom
    125,585 pointsBadges:
    report
  • bvining
    One alternative available to you is to use the ExtremeCL Date and Time commands. Using the Change Date Variable (CHGDATXCL) command the following program returns a &ToDate value of 3043/266 (the default of the DATSEP keyword is to return a date separator based on the format). Pgm                                            Dcl        Var(&FromDate) Type(*Char) Len(8) +              Value('30430923')                 Dcl        Var(&ToDate)   Type(*Char) Len(10)  ChgDatXCL  Var(&ToDate) Fmt(*LongJul) +                     BasVal(&FromDate) BasFmt(*YYMD)   EndPgm                                         As you can see, 2070 is not a concern with the ChgDatXCL command. The command documentation can be found at http://www.powercl.com/images/stories/cmdxcldt.html The Date and Time commands are available starting with V5R4 and with a one-time charge of less than 20 dollars (US) generally don't cause much in the way of budget problems. Though not shown, the ChgDatXCL command also has a Date adjustment (DATADJ) keyword that allows you to add or subtract up to 50 durations (add &X months, subtract &Y days, etc). Similar commands are included for time and timestamp variables. Please note that I do work for the company offering this command. Bruce Vining
    6,475 pointsBadges:
    report
  • TomLiotta
    You can also simply not use CVTDAT at all. The ILE CEE Convert Date to Lilian Format (CEEDAYS) and Convert Lilian Date to Character Format (CEEDATE) APIs can convert between any reasonable formats for dates from 14 October 1582 to 31 December 9999.   Call those in a procedure with or without using a command wrapper, or code them directly into ILE CL. The CVTDAT command is convenient for common uses. But if you can't get past its limitations, you need to do some programming.   Tom
    125,585 pointsBadges:
    report
  • bvining
    A minor point perhaps, but not using the century digits will result in correct conversions roughly 99.003+ % of the time. Anyone care to guess why 00.006+ % will be wrong?
    6,475 pointsBadges:
    report
  • TomLiotta
    Only a minor point if it doesn't need to be handled. But I seem to recall that you've done some work with internal calendars in detail, so you've got some useful experience and probably useful info. First thing I'd be concerned about with Julian dates would be the actual range of dates that had to be covered. For example, I'd be nervous about a date projected past early 2100.or back into 1900. What else? -- Tom
    125,585 pointsBadges:
    report
  • asakla
    Yes we require date in julian format to determine the day of the week , the week no , and no of days elapsed in the year and left in  the year ....

    For this CVTDAT limitation of 2039 we created a new Command now same as CVTDAT but no limitation on year , 
    As we will be taking the Input Year as YYYY instead of YY , So this Solves the problem for us 
    240 pointsBadges:
    report
  • TomLiotta
    we require date in julian format to determine the day of the week , the week no , and no of days elapsed in the year and left in  the year ...   In that case, you might be better off using the SQL DAYOFYEAR() and WEEK() (or WEEK_ISO()) Scalar functions.   Tom
    125,585 pointsBadges:
    report
  • bvining
    Tom, You have correctly identified the problem years when working with Julian dates that do not provide century digits. Using 2-digit years CVTDAT would assume the year being processed is 2000, which has a leap day. Both 1900 and 2100 on the other hand do not have leap days, so julian day of year mapping with formats such as *YMD would cause incorrect day values, in those years, for days past February 28.
    6,475 pointsBadges:
    report
  • gfprogrammer

    As Bruce pointed out 1900 and 2100 are not leap years.  To be a leap year the century must be divisible by 400 and not 4 as other leap years. We were luck for the year 2000. 

    I will not have the "pleasure" to  see how the next century dates will be programmed but it should be interesting.  Banks and mortgage companies will have to start thinking about this in a few short years.

    250 pointsBadges:
    report

Forgot Password

No problem! Submit your e-mail address below. We'll send you an e-mail containing your password.

Your password has been sent to:

To follow this tag...

There was an error processing your information. Please try again later.

REGISTER or login:

Forgot Password?
By submitting you agree to receive email from TechTarget and its partners. If you reside outside of the United States, you consent to having your personal data transferred to and processed in the United States. Privacy

Thanks! We'll email you when relevant content is added and updated.

Following