Comments on: 2039 Year Limitation in CVTDATE

By: gfprogrammer

gfprogrammer — Mon, 10 Dec 2012 22:57:56 +0000

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.

By: bvining

bvining — Fri, 07 Dec 2012 17:42:19 +0000

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.

By: TomLiotta

TomLiotta — Fri, 07 Dec 2012 06:34:11 +0000

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

By: asakla

asakla — Fri, 07 Dec 2012 05:37:17 +0000

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

By: TomLiotta

TomLiotta — Fri, 07 Dec 2012 05:20:02 +0000

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

By: bvining

bvining — Fri, 07 Dec 2012 03:32:25 +0000

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?

By: TomLiotta

TomLiotta — Thu, 06 Dec 2012 22:09:44 +0000

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

By: bvining

bvining — Thu, 06 Dec 2012 14:26:36 +0000

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

By: TomLiotta

TomLiotta — Tue, 04 Dec 2012 12:36:13 +0000

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

By: asakla

asakla — Tue, 04 Dec 2012 12:10:56 +0000

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