Date Conversion

We’ve all looked at ways to convert date values between character, numeric and date data types. There are several cheat sheets online, but I couldn’t find any examples of anyone attempting a more modular approach to this problem. So, I created a service program containing several procedures that allow a calling program to retrieve any possible combination of data type and from/to date format. This endeavor would have been much less tedious if the compiler would allow us to use variables to contain the format values, but that is not the case with the current release.

CALLING THE PROCEDURES

There are 8 procedure calls which can accomplish each type of conversion:

$Duratn_CvtDate#ToDate 

Purpose: converts a date contained in a numeric field to a date data type

Input: (1) numeric field containing a date; (2) format value of the input numeric date (optional, ISO is the default)

Return: (1) date data type; (2) success indicator

$Duratn_CvtDate#ToDateChr

Purpose: converts a date contained in a numeric field to a date contained in a character field

Input: (1) numeric field containing a date; (2) format value of the input numeric date; (3) desired format value of the output character field date

Return: (1) character field containing a date; (2) success indicator

$Duratn_CvtDateChrToDate

Purpose: converts a date contained in a character field to a date data type

Input: (1) character field containing a date; (2) format value of the input character date (optional, ISO is the default)

Return: (1) date type; (2) success indicator

$Duratn_CvtDateChrToDate#

Purpose: converts a date contained in a character field to a date contained in a numeric field

Input: (1) character field containing a date; (2) format value of the input character date; (3) desired format value of the output numeric field date

Return: (1) numeric field containing a date; (2) success indicator

$Duratn_CvtDate#ToDate#

Purpose: converts a date contained in a numeric field to a date contained in a numeric field

Input: (1) numeric field containing a date; (2) format value of the input numeric date; (3) desired format value of the output numeric field date

Return: (1) numeric field containing a date; (2) success indicator

$Duratn_CvtDateChrToDateChr

Purpose: converts a date contained in a character field to a date contained in a character field

Input: (1) character field containing a date; (2) format value of the input character date; (3) desired format value of the output character field date

Return: (1) character field containing a date; (2) success indicator

$Duratn_CvtDateToDate#

Purpose: converts a date contained in a date data type to a date contained in a numeric field

Input: (1) date data type; (2) desired format value of the output numeric field date (optional, ISO is the default)

Return: (1) numeric field containing a date; (2) success indicator

$Duratn_CvtDateToDateChr

Purpose: converts a date contained in a date data type to a date contained in a character field

Input: (1) date data type; (2) desired format value of the output character field date (optional, ISO is the default)

Return: (1) character field containing a date; (2) success indicator

RPG looks more like an OOP language with every release. Because these procedures shared similar functionality and return values, I was able to incorporate polymorphism into the solution by using the overload keyword in their respective prototypes. As a result, these 8 procedures were reduced to 3 calls.

• Procedure $Duratn_ConvertToDate is called if either a numeric or character field contains a date that is to be converted to a date data type.

• Procedure $Duratn_ConvertToDate# is called if a numeric, character, or a date data type contains a date that is to be converted to a numeric date.

• Procedure $Duratn_ConvertToDateChr is called if a numeric, character, or a date data type contains a date that is to be converted to a character date.

This approach simplified the number of calls that need to be made. However, the overloaded prototype will not be recognized if using binding source.

FUNCTIONALITY

All procedures follow the same general process. First, date type formats are validated based on the data type of the date being passed. If the date type formats are valid, the input date is validated. If any of these tests fail, the success indicator is turned off and the procedure ends. Otherwise, the dates are converted and the success indicator is turned on. The following are the valid values for each of the two types of variables:

Numeric date formats: 

• CDMY 
• CMDY
• CYMD
• DMY 
• EUR
• ISO
• JIS
• JUL
• LONGJUL
• MDY
• USA
• YMD

Character date formats:

• CDMY with or without the following separators: dash, ampersand (blank separator), comma, period, slash, zero (no separators)
• CMDY with or without the following separators: dash, ampersand (blank separator), comma, period, slash, zero (no separators)
• CYMD with or without the following separators: dash, ampersand (blank separator), comma, period, slash, zero (no separators)
• DMY with or without the following separators: dash, ampersand (blank separator), comma, period, slash, zero (no separators)
• EUR with or without the following separators: period, zero (no separators)
• ISO with or without the following separators: dash, zero (no separators)
• JIS with or without the following separators: dash, zero (no separators)
• JUL with or without the following separators: dash, ampersand (blank separator), comma, period, slash, zero (no separators)
• LONGJUL with or without the following separators: dash, ampersand (blank separator), comma, period, slash, zero (no separators)
• MDY with or without the following separators: dash, ampersand (blank separator), comma, period, slash, zero (no separators)
• USA with or without the following separators: slash, zero (no separators)
• YMD with or without the following separators: dash, ampersand (blank separator), comma, period, slash, zero (no separators)

TESTING

The test plan consisted of all possible combinations of data types and date formats for both the input parameters and returned values.  It also verified that invalid dates (99999) and formats (“XXX”) were omitted from processing after the success indicator was set to OFF.  Over 18k records were generated and their results were documented in an output file which was downloaded to an Excel spreadsheet for validation. Each date format version of June 13, 2024 was used as a test date for each scenario. 

The resulting document confirmed that in every case, the expected success indicator value matched the resulting success indicator value. Similarly, it also demonstrated that all of the returned values matched what was expected. The spreadsheet can be downloaded below.