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



Yikes... I can't believe we're still trying to solve Y2K problems in 2008!! Also, your subject refers to the date as '6s 0' (zoned decimal) but your code refers to it as 'Char_Date'. Is it character or zoned decimal?!

Anyway... this is the approach that I've taken (pseudocode):

// convert mmddyy to yymmdd

if yymmdd > currentDate;
yyyymmdd = '19' + yymmdd;
else;
yyyymmdd = '20' + yymmdd;
endif;

// convert yyyymmdd to a date field

This works on the premise that nobody is born in the future. So if the date is later than today's date, the century MUST be lower than today's century.

Unfortunately, it does not work with people who are more than 99 years old... Depending on the purpose of the field, it might make sense to subtract a few years from the current date. For example, we have done this type of logic on our personnel records -- and, of course, we don't hire anyone younger than 15 years old, so we do this:

// convert mmddyy to yymmdd

if yymmdd > ( currentDate - 14 years);
yyyymmdd = '19' + yymmdd;
else;
yyyymmdd = '20' + yymmdd;
endif;

// convert yyyymmdd to a date field

That means it'll work for someone that's up to 114 years old, which is good enough for us... though, I guess it depends on how long you keep your personnel records! You may have employees from the 1960's who are still in your records despite being born more than 114 years ago, I don't know?

But, obviously there's only so much you can do when the fields don't actually have part of the information you need! You may be able to guess it correctly in MOST cases, but not every single time. The correct fix is to get the dates entered PROPERLY.... didn't we learn anything from Y2K?


DLee@xxxxxxxx wrote:
Could use some help;

My client is sending a file of birthdates and loan effective dates in mmddyy format;

For example:

A birth date of 062337 translates to 2037/06/23 Common sense dictates this is not a valid birth date and would be 1937/06/23

Below Char_Date = 062337 and translates to 2037-06-03 in ISODATE.

What would be best practice for handeling this problem?

C *MDY TEST (D) Char_Date 19
C IF *IN19 = *OFF
C *MDY MOVE Char_Date ISODATE
Appreciate your help

Yeah I know, fixed format. Brr sldkfhgj
Darrell Lee
Information Technology
Extension 7127


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.