Date and time in EDI
The trick to dealing with date and time in an X12 EDI document is to make things easy for yourself. EDI isn’t going to do that for you. EDI makes it possible to put a date on a business document in any way a human being has ever come up with and that flexibility comes at a cost: it’s downright confusing. You don’t have to deal with that confusion, though, because you don’t have to deal with that flexibility. It all starts with the implementation guide that you received from your trading partner.
The implementation guide tells you what your trading partner expects from you. If your trading partner will send you purchase orders, then the implementation guide will tell you what those purchase orders look like. Every trading partner will format it a bit differently, but it usually looks something like this.
Of course, I don’t know who you’re trading with and I don’t know which type of documents you’re dealing with, so I’ll probably cover a bit more ground here than you need. Just remember: refer to the implementation guide and ignore everything that’s not in there, lest you drive yourself mad.
If your trading partner sends you a document, you might expect dates to look something like this.
However, EDI is different. It looks like this instead.
DTMmeans that the segment represents a date and time.
EDI actually has three different segments to represent date and time: DTM, DTP, and G62. DTM is the most common, but it’s also the most complicated, so I’ll talk about that one last. Fortunately, everything I’ll show you about G62 and DTP also applies to DTM.
To add to the complexity, date and time are not always expressed with one of these dedicated segments; sometimes they’re embedded into completely different segments. Those segments take bits and pieces of the dedicated date-and-time segments and call them their own.
The G62-segment represents a date like this.
The last element of the segment isn’t too hard to understand: it’s the actual date. It’s always in the format YYYYMMDD. There’s also an element in the middle and it isn’t immediately clear what it means. Suppose you have a document for a shipment status update that contains two different dates.
"shippedDate": "2022-04-28" "estimatedDeliveryDate": "2022-04-29"
In EDI, that would look like this.
Shipped on This Dateand
Estimated Delivery Date. If you take a look at the full list of possible codes, you’ll see that there are 137 of them. That’s a lot. They all have names, but those don’t do a good job of explaining what they mean. That’s when you turn to the implementation guide your trading partner gave you.
17. That makes sense, because a code like
BC - Publication Datedoesn’t mean anything in the context of a shipment status update.
G62example I gave only shows a date, but a
G62can contain a time as well. In fact, the full specification of a
G62looks like this.
Again, the implementation guide will tell you whether you need the full segment, but since we’ve already seen an example of a date, let’s take a look at an example of a time.
*is still there, otherwise we wouldn’t know how many fields we skipped. So, that’s what those three stars between
8mean: skip the two date fields.
1547is the time: 3:47 PM. It’s always specified in a 24-hour clock. The example shows the shortest time format possible, but times can also have seconds and even fractions of seconds.
If you want to be sure which format you need to handle, you’ll have to check the implementation guide.
8in the example is a code for the kind of time you’re dealing with, just like
17were codes for the kind of date.
Actual Pickup Time. You could look up all the possible codes, but it’s better to refer to your implementation guide.
Equivalent to ISO P08means UTC+08 and
Equivalent to ISO M03means UTC-03. In other words, the number at the end is the offset from UTC where
LT, which means
Local Time. It depends on the context which time zone that is. If you’re dealing with a shipment status update, then it stands to reason that the local time for the pickup is local to wherever the pickup occurred.
G62can represent both a date and a time, it can also represent a date-time.
11) and a time qualifier (
8) in the same segment, since they convey similar information, but check your implementation guide to be sure.
The DTP-segment is also used to express dates and times, but it’s more flexible than the G62-segment. DTP can express almost everything G62 can—except for time zones and fractions of seconds—and it has some extra features on top.
A simple date looks like this.
Shipped, so that’s the same as with the G62, even if it’s describes slightly differently. The entire list of possible codes for the DTP is much longer, though; more than a thousand possibilities. Definitely check your implementation guide to see which ones are relevant to you.
D8means that this is a date in YYYYMMDD format. This is where DTP becomes more flexible than G62: you can use different formats. For example,
D6means a date in YYMMDD format,
TTmeans a date in MMDDYY format, and
CYmeans a date expressed as a year and a quarter, e.g.
20221means Q1 of 2022. That last one is interesting, because there’s no way to express the concept of a quarter in a regular date format. There’s even the notion of a Julian date, which just numbers days consecutively, starting on January 1st and it’s particularly fun to deal with in leap years. I imagine Julian dates are rare, but hey, if you need it, you need it.
DTP can do time as well.
TMmeans a time in HHMM format and, as with G62, DTP always uses a 24-hour clock. Another code is
TS, which means a time in HHMMSS format. There’s no code that allows you to specify fractions of a seconds, so that’s a feature of G62 that DTP doesn’t have. DTP also doesn’t provide a way to specify a time zone.
Expressing a date-time doesn’t require any extra fields, just a different format qualifier.
DTmeans a date-time in YYYYMMDDHHMM format and the date-time in the example is April 28, 2022 at 3:47 PM. If the qualifier is set to
DT, the date-time will include seconds as well.
Where DTP truly trumps G62, is in its ability to represent date ranges.
RD8means a date range in YYYYMMDD-YYYMMDD format. There are also ranges that include a time, and ranges that use only years, and everything in between. You can check out the full list of qualifiers, but it’s even better to check your trading partner’s implementation guide.
The DTM-segment is the most common way of representing date and time in EDI. It’s also the most flexible, because it has the capabilities of both the G62-element and the DTP-element. That would also make it the most confusing, except that you’ve already seen G62 and DTP, so there’s nothing left to say about DTM.
As you can see, it’s just a combination of the G62-elements and the DTP-elements. You do need to figure out which of these elements are used and which are ignored, but by now, you know how to do that as well: check the implementation guide.
EDI Reference provides users with documentation on all transaction sets, segments, and elements of every X12 release, and all message types, segments and elements of every EDIFACT version.
Get blog posts delivered to your inbox.