EIDX Date Information Contents

• Date Segments and Elements
• Types of Dates
• Date Formats and Identifying Century

UN EDIFACT
In UN EDIFACT, the DTM segment is used for all dates. The position of the DTM segment indicates what related data the date applies to. For example, when the DTM follows an RFF segment containing a Purchase Order Number, the DTM specifies the date and/or time related to the Purchase Order. The Date/Time/Period Qualifier on the DTM itself indicates what specific type of date is being sent. In the case of a Purchase Order Date, the date might be an Order Date, an Expiration Date, or some other type of date.

ASC X12
ASC X12 has two methods for specifying dates. Some dates are in a fixed position on specific segments. For example, BEG05 on the BEG segment in the 850 Purchase Order is specifically the Purchase Order Date. In other cases, DTM segments are used. As with UN EDIFACT, the position of the DTM segment indicates the related data to which the date applies.

In older ASC X12 versions, dates in specific positions such as Purchase Order Date (DE323) had their own data element number. As of version 3050, all date fields are assigned Date (DE374), whether the date occurs in a specific position on a specific segment or in the DTM segment. Even if Date (DE374) is within a segment other than the DTM segment, the date definiton is still pre-defined according to that position. For example, the BEG05 is the Date (DE374) but there is a comment that states that BEG05 is the Purchase Order Date.

Return to Contents

Tracking Dates
The buyer’s request schedule dates should not be confused with the seller’s scheduled dates, e.g., the PO is requesting a date of March 1, but the supplier must set the expected shipment date of March 8. It is advisable that the buyer’s latest requested ship dates or latest and first requested delivery dates be tracked in the seller’s system.

Return to Contents

This section discusses the problem of the traditional date format YYMMDD, where YY is the last two numerics in year 19YY or 20YY, MM is month (01-12), and DD is the day of the month (01-31), as the next century approaches. Many segments used in older ASC X12 version/releases contain a date data element in the YYMMDD format, which must have special reviews as dates in the next century are used in EDI transactions.

The business application needs to know the century because applications are date driven. It must know that date 001231 is after 991231. For example, December 31, 2000 is after December 31, 1999 though the six position number 001231 would sort before 991231. If the date arrives as 001231, a receiving trading partner could convert the date to 20001231.

UN EDIFACT
| The UN EDIFACT standard has Date/Time/Period (DE2379) which allows all combinations of date and time. Consequently, EDIFACT allows for specifying century within standard dates.

ASC X12 DTM Segment Development
Early ASC X12 version/releases allowed only one date format YYMMDD.

In version 3020, DE624 Century was added as DTM05. Century is a two position field to hold the 19 or 20 portion of the CCYY year where CC is the century and YY is the last two numerics in the year. In version 3040, DE1250 Date Time Period Format Qualifier (DTM06) and DE1251 Data Time Period (DTM07) were added to the DTM segment. These latter data elements correlate to the EDIFACT 2380 and 2379 data elements.

Any date data element embedded within other segments, e.g., DE373 DATE, remains formatted as YYMMDD at least through version 3070. ACS X12 plans the expansion of DE373 DATE to format CCYYMMDD in a future version/release (as of this writing, this should be version 3071 in mid-1997; version 4010 should be available in January 1998).

Technically in ASC X12, all dates will carry the ‘hundred year’ CC portion. The ‘CC’ is not referred as ‘century’. The ‘hundred year’ term should avoid any confusion that the ‘twenty-first century’ starts in year 2001; it does not start in the year 2000.

Examples - Date is March 8, 1997 and time is 09:12:34 Greenwich Mean Time:

Consideration 1: Application Dates vs Transaction Dates
The next century dates are a greater burden in the business application which must process the date than in the EDI translator. The receiving trading partner’s EDI translator, application, or application interface can format the date/time into any format that the application needs. It can determine ‘19’ or ‘20’ for century if it was not found in the transaction; it can remove ‘19’ or ‘20’ if it arrives but it is not needed by the receiving process. The goal is to present the date/time in a format to allow dates to be interpreted properly. Even dates formatted CCYYMMDD may not be the date format required by the receiving application. The receiving process will format the date to meet their application requirements.

The need to determine the next century dates will occur before year 2000, particularly in contract and forecast data. Until the receiving trading partner can process the eight (8) position date, or twelve (12) position date/time, there is processing overhead to convert every date. Date conversions should be considered a temporary conversion to be used only until systems and applications can all be upgraded to handle the new format.

Consideration 2: Transactional Alternatives
The first three of the following exisiting alternatives are preferred by EIDX:

• Use EDIFACT messages.
• Transaction Receiver determines century and their full date/time format by their chosen method if century is not explicit in the segment.
• Wait until the ASC X12 4010 version/release which will accommodate the new format and encourage all trading partners to use at least that version/release of the data dictionary.
• Sender formats additional DTM segments with the full date to add to the transactions only where appropriately positioned in the transaction.

Use EDIFACT Messages
Since EDIFACT explicitly defines the full date, the dates are clear to the Trading Partners. The EDI Translator still must map the data to the format needed by the application. The use of EDIFACT messages must be agreed upon trading partners.

Receiver Determines Full Date
With the current YYMMDD date format, the receiving party develops an algorithm to determine the century given any YYMMDD formatted date. Then they apply the algorithm in the EDI translator or an application interface to determine century and format the date for the application. See the following section on "Date Windows".

Additional DTM Segments
Technically, some DTM segments can be used in transactions to take advantage of the full date notation. They may cause confusion if the date is both embedded in the original segment plus the additional DTM segment. This method may require the receiving party to create a new data map for the trading partner to recognize the DTM if the embedded date field no longer contains the date. Also if the DTM segment is repeated, the data map has to be intelligent enough to determine which DTM segment contains the desired date.

Note that the DTM segment is not always positionally available in the transactions were it is needed to convey the extended date format. For example, Date/Time (DTM) segments do not exist after schedule (SCH) segment in the purchase order.

The receiver may still need an algorithm to determine full dates since not all embedded dates have correlated positioned DTM segments. The mixture of date methods may cause confusion.

For example, in the purchase order transaction the following segments are allowed:

Consideration 3: Date Windows
A date window is the establishment of a year range to be assigned the century code 19 versus century code 20. The algorithm may be based on a fixed range or sliding range as noted in the following table. Most industries can process data within a one hundred (100) year date range. Most industries are not likely to misinterpret the year 95 to be 2095, while they are processing around 1995.

The insurance industry may encounter system problems since they calculate ages and their customers can live more than 100 years. If one is born in 1899 and dies in 2001 at 103, transferring the date correctly is critical. The wrong assumption on the date will have this person living only between 1999 and 2001, just two years!

Each trading partner can establish their own date range to default the century in their processing. For example, a trading partner processes a YYMMDD date where YY is between 78 and 99, it can be safely assumed that the Century is ‘19’. When processing a YYMMDD date where YY is between 00 and 77, it can be safely assumed that the century is ‘20’. The needs of the particular application and type of data should be taken into account when deciding whether or not to use this algorithm.

CompTIA EIDX Recommendations for Dates
We recommend that 1) century be used as part of the date/time format wherever possible in the segment, and 2) use the date windowing technique when no DTM segment is available and the six position date must be used. Until ASC X12 provides for century within every DATE data element, it is the responsibility of the receiver to determine the century given the YYMMDD formatted date. The sender of the transactions should not complicate their transactions with additional DTM segments after segments with correlated embedded dates.

For UN EDIFACT data, the codes in the table below are the core set of codes recommended by EIDX. UN EDIFACT does not have a separate field for century; century is included in the date format.

In ASC X12, EIDX recommends the usage of DTM06 and DTM07. These data elements are described in the table below. Use DTM06 set to ‘D8’ for CCYYMMDD. The receiving trading partner can remove the CC value in their EDI translator if they can only process the YYMMDD.

The receiving partner will process time however they wish and split time from DATE if necessary.