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.

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

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

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

Hi TOM , I tried the Long Julian it works But it also has a limitation beyong 2070 …

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

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

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

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?

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

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

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

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.

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.