× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.



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


As an Amazon Associate we earn from qualifying purchases.

This thread ...

Replies:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.