Re: Date validation of different formats in RPG

[Scott Klement <klemscot@xxxxxxxxxxxx>]

>  Scenario: we receive data from various sources, each one of which seems to
> have a different idea of how dates should be formatted. Here in the US most
> data entry operators use *MDY format, but others feel free to use *MDY0,
> *USA, etc, etc. Demanding consistency won't work - these are our customers
> and part of the 'value' our company offers is to allow them to send data in
> the format they feel comfortable with.

If the dates are always *MDY or *USA, then you should be able to easily
distinguish between them.  Remove any non-numbers from the dates, the
result will be either 6 or 8 characters long, 6 chars is MDY, 8 is USA.

However, if the dates can be in any format, you've got a problem.
Consider the date "010203", in MDY format it means Jan 02, 2003.  In YMD
it means Feb 03, 2001.  In DMY it means Feb 01, 2003.  All are valid
dates... there's no way to know which is acceptable.

And then, what about dates like "31-MAR-2004" or "31MAR04" or "Mar 31,
2004" or "March 31, 2004"?   Those are valid, but would fail all of your
TEST(DE) checks...


> At the time they need to validated, the dates have already been parsed into
> 10A fields in a subfile program, I'm considering writing a procedure to make
> a 'best-guess' as to the date's format - something akin to the code below.
> Someone has to have addressed this situation before - would you care to give
> out a few pointers?

Somewhere along the line, you're going to have to either get input from a
user or make some assumptions.

Personally, I would assume that a field in a file will be consistent for
that entire file.  I would give your operator the ability to select what
the date formats for each field are and then store that somewhere...

I'd use the CEEDAYS API to parse the date rather than TEST(D)/MOVE because
it allows you to specify a picture string.  Save the picture string used
by a given customer/field into a file.  When it's time to read that file,
read back that picture string and have CEEDAYS parse the field.

If you do want to use the (very error prone) "check every possible
format" method, then I'd still recommend using the CEEDAYS API, simply
because you can use an array of picture strings and a loop, rather the
ugly if/else/if/else logic.

Something like this (untested):

c                   eval      fmts(1) = 'MMDDYY'
c                   eval      fmts(2) = 'ZM/ZD/YY'
c                   eval      fmts(3) = 'MMDDYYYY'
c                   eval      fmts(4) = 'ZM/ZD/YYYY'
c                   eval      fmts(5) = 'Mmm ZD, YYYY'
c                   eval      fmts(6) = 'Mmmmmmmmmz ZD, YYYY'

c                   eval      formatfound = 0

c                   for       x = 1 to 6
c                   callp(e)  CEEDAYS(date_in: fmts(x): date_out: *omit)
c                   if        not %error
c                   eval      formatfound = x
c                   leave
c                   endif
c                   endfor

Then, of course, use CEEDATE to convert it to a date format that's useful
in your program...

I posted another example of CEEDAYS (which I did test) as well as links to
the documentation in this message:
  http://archive.midrange.com/rpg400-l/200403/msg00151.html

But, again, the best recommendation that I can give you is to have to
operator create a profile of some sort that describes, for a given field,
what the date format will be -- guessing at the format will never be
reliable.