Clickable Business Models eBusiness Education Acronyms Cross References
B2B Content Standards EC Technology Standards Glossary Implementation Guidelines
Implementation Options General Recommendations References Methodology/Legends
 Home | Copyright Notice and Legal Disclaimers | Navigation Help | Tour! | Downloads | Contact Us | Site Index | Search
 Product Identification | Partner/Location IDs | Doc/Reference IDs | Dates | Other Best Practices |
EIDX General Supporting Documentation
Status:  Provisional draft.  Adapted from previous published version (Balloted and Ratified by Membership, June 1997)

Dates


Contents


Date Segments and Elements

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.

EDIFACT
DTM Segment

DATE/TIME/PERIOD SEGMENT
blank_space.gif (96 bytes)
Composite Element

Min/Max

blank_space.gif (96 bytes) blank_space.gif (96 bytes)
C507 blank_space.gif (96 bytes) Date/Time/Period (composite) blank_space.gif (96 bytes)
2005

1/3

Date/Time/Period Qualifier Code to Distinguish the type of date, e.g. ship date, delivery date, payment date
2380

1/35

Date/Time/Period Actual date and/or time
2379

1/3

Date/Time/Period Format Qualifier Code to indicate the date format. See "Date Format" below.

 

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.

ASC X12
DTM Segment

DATE/TIME SEGMENT
blank_space.gif (96 bytes)
Position Element

Min/Max

blank_space.gif (96 bytes) blank_space.gif (96 bytes)
DTM01 374

3/3

Date/Time Qualifier Code to Distinguish the type of date, e.g., ship date (011), delivery request (002)
DTM02 373

6/6

Date Actual YYMMDD Date. If DTM02 is used, DTM06/DTM07 should not be used. See "Date Format" below.
DTM03 337

4/8

Time Actual HHMM time. If DTM03 is used, DTM06/DTM07 should not be used. See "Date Format" below.
DTM04 623

2/2

Time Zone Qualifier (Time Code) blank_space.gif (96 bytes)
DTM05 624

2/2

Century CC: first 2 numbers of a year, ‘19’ or ‘20’ to indicate century. EIDX recommends that if DTM02 is used to convey YYMMDD date, that DTM05 be used also to convey century.
DTM06 1250

2/3

Date Time Period Identifier Code to indicate the date format. See "Date Format" below. If DTM06 is present, DTM07 is required, and DTM02/DTM03 should not be used. See "Date Format" below.
DTM07 1251

1/35

Date Time Period Actual date/time as qualified in DTM06.

 

Return to Contents


Types of Dates

The following table identifies recommended usage for the core date qualifiers used by EIDX.

X12 (DE374)

UN C50701 (DE2005)


MEANING

OMMENT

002
010

2
10

Delivery Requested
Requested Ship
Use to convey the buyer’s required date in actual schedules, or for "dummy" schedule only per trading partner agreement.

017

17

Estimated Delivery Used by a seller to send an acknowledgment date to a buyer in cases where the seller does not control the means of transportation (carrier, consolidator, freight forwarder, etc.), and therefore it cannot control the exact delivery date.

036
038
063

36
38
63

Expiration (Coverage Expires)
Ship No Later
Do Not Delivery After
1) Use per literal meaning
2) Some types of Blanket POs (BPOs) are issued without schedules, but the trading partner may need at least one "dummy" schedule due to systems requirements; use for "dummy" schedules if BPO has an expiration date. In the date element, use the BPO’s expiration date.

067
068

67
79

Current Schedule Delivery
Current Schedule Ship
Used by seller in acknowledgments or re-acknowledgments to specify the current acknowledged schedule date, as opposed to the customer’s current request date.

N/A
N/A

157
158

Horizon Start Date
Horizon End Date
Use to specify date ranges / time periods. In X12, horizon dates are located in specific positions on segments, so there are no DE374 codes for these dates.

037
064

37
64

Do Not Ship Before
Do Not Deliver Before
1) Use per literal meaning
2) Some types of Blanket POs (BPOs) are issued without schedules, but the trading partner may need at least one "dummy" schedule due to systems requirements;
Use for "dummy" schedules if BPO is quantity-based with no set expiration date and no pre-defined schedules. In the date element, use the effective date or the issue date of the BPO.

 

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

 


Date Formats and Identifying Century


EIDX recommends that Year 2000-compliant versions of the standards be used. 

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.

EVOLUTION OF DTM SEGMENT




Position




Data Element



ASC X12 Data Element


EDIFACT Data Element



ASC X12 Min/Max




Values

First ASC X12 Version/Release

DTM01

Date /Time Qualifier

374

blank_space.gif (96 bytes)

3/3

blank_space.gif (96 bytes)

2001

DTM02

Date (YYMMDD)

373

blank_space.gif (96 bytes)

6/6

blank_space.gif (96 bytes)

2001

DTM03

Time

337

blank_space.gif (96 bytes)

4/8

blank_space.gif (96 bytes)

2001

DTM04

Time Code

623

blank_space.gif (96 bytes)

2/2

blank_space.gif (96 bytes)

2001

DTM05

Century

624

blank_space.gif (96 bytes)

2/2

19 or 20

3020

DTM06

Date/Time/Period Format Qualifier

1250

2380

2/3

blank_space.gif (96 bytes)

3040

DTM07

Date/Time/Period

1251

2379

1/35

blank_space.gif (96 bytes)

3040

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

[email protected]

[email protected]

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: TRANSACTION ALTERNATIVES

The following alternatives exist:


The first three alternatives are preferred by EIDX.

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

Purchase Order (850) Sample Note

[email protected]

Trading Partner determines the date format needed by the application.

 

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:

Purchase Order (850) Sample

Note

BEG~00~SA~PO5467 @

or [email protected]

PO date in BEG06 Is optional.

[email protected]

Additional segment for PO Date.

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.

 

Rule 1

Rule 2

Fixed Range:

Years ending in 78-99, assume century 19. (Each system determines its own starting number) Years ending in 00-77, assume century 20.

Sliding Range:

Current year MINUS x-years and PLUS y-years, assume century 19.

X-years and Y-years are any number determined by the trading partner. ‘X’ may be 15 years back and ‘Y’ is 3 years forward; however, each new year changes the window and adjustments must be made to make the century accurate.

In 1997, the 15 years back and 3 years forward is 1985-1999.
In 1998, the 15 years back and 2 years forward is 1986-1999.
Otherwise, assume century 20.

 

Recommendations for Dates

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

ASC X12 (DE1250) (DTM06)

UN (C507:
2379)



MEANING


COMMENT

D6

101

YYMMDD Format used by most legacy systems.
DTM*002*****D6*970308

D8

102

CCYYMMDD Recommended by EIDX for dates.
DTM*002*****D8*19970308

No code

201

YYMMDDHHMM ASC X12: Not recommended by EIDX.
Use the separate date and time fields provided for elsewhere on the DTM segment or other segments containing the time element (DE337).
DTM*002******19970308

UN: Format used by most legacy systems when date and time are being specified.

DT

203

CCYYMMDDHHMM Recommended by EIDX when also specifying time.
DTM*002*****DT*199703082330

TM

401

HHMM Use when it is only necessary to specify time without specifying date.
DTM*002*****TM*2330

Last updated 06 February 2003