Re: Date conversion from m/d/ccyy format

InFollowingThisThread,I'veHadTheCEE*Date/timeFunctionsInTheBackOfMyMind.(TheSpaceBarOnThisLaptopIsDying!ReplacementDueToArriveNextWeek.)

CEESECS converts a picture string into some number of seconds since sometime. It lets you omit leading zeroes - here is an interesting bit from the docs -

Each character in *picture_string* represents a character in *input_timestamp*. If delimiters such as the slash (/) appear in the picture string, leading zeros may be omitted. For example, these calls assign the same value to the variable /secs/.

CALL CEESECS('88/06/03 15.35.03',
'YY/MM/DD HH.MI.SS', secs, fc);

CALL CEESECS('88/6/3 15.35.03' ,
'YY/MM/DD HH.MI.SS', secs, fc);

CALL CEESECS('88/6/3 3.35.03 PM',
'YY/MM/DD HH.MI.SS AP', secs, fc);

CALL CEESECS('88.155 3.35.03 pm',
'YY.DDD HH.MI.SS AP', secs, fc);



On 3/24/2012 12:22 AM, John Yeung wrote:

On Fri, Mar 23, 2012 at 6:53 PM, Barbara Morris<bmorris@xxxxxxxxxx> wrote:

On 2012/3/23 11:28 AM, John Yeung wrote:

For the *USA format, %DATE handles single
digits for both month and day.

That's not a documented feature. RPG officially
requires that the month and day each have two
digits, with leading zeros if necessary.

That is what I expected, but I tried it out on the V5R2 machine at
work, and the leading zeros were not needed.

Chuck's message suggests maybe the language implementation was
tightened up to better match the docs in subsequent versions. In my
opinion, this is not a good direction. Working with dates is such a
ridiculously common thing to do, and so, so easy for the compiler to
handle this kind of thing, why force everyone to roll their own?
Sure, folks who know what they're doing will probably just put it in a
service program and always call it from there, but... it just seems
like such a waste. (And you *know* some folks will not implement
their routine correctly. How many incorrect home-brew leap-year
calculators are out there? Way too many to count.)

John