Audience: EDI developers, B2B integration teams, trading partner technical contacts

Dates and times appear throughout X12 EDI transactions — in envelope headers, transaction beginning segments, and dedicated date/time segments. Each context has its own format requirements and rules. This article covers where dates and times appear, how they must be formatted, how timezones are handled, and how to fix common date and time errors.

The ISA and GS segments carry the date and time the interchange and functional group were created. These are set by Orderful automatically and are not part of your transaction payload.

Note: ISA09 intentionally uses a 2-digit year (YYMMDD), not CCYYMMDD. This is a fixed-length segment constraint in the X12 standard that has not changed. Do not use a 4-digit year in ISA09.

Most transaction types have a beginning segment that carries the document date as a standalone field — not paired with a qualifier. This date represents the business date of the document itself (invoice date, PO date, shipment date, etc.).

The DTM (Date/Time Reference) segment is the general-purpose date and time segment in X12. Unlike beginning segment date fields, every DTM date is paired with a qualifier (DTM01) that defines what the date means. The same segment structure is reused throughout a transaction for different date types — ship date, delivery date, requested date, and so on.

Structure:

Example:

This means: shipped on October 23, 2025 at 3:59 PM local time.

The G62 segment carries transportation-related dates and times in freight transactions (204, 211). It works similarly to DTM — G6201 carries a qualifier code that defines what type of date is being communicated, G6202 carries the date in CCYYMMDD format, and G6204 carries the time in HHMM format. The qualifier codes used in G6201 overlap significantly with DTM qualifiers — see the qualifier table below.

AT7 (214 shipment status) carries the event date in AT705 (CCYYMMDD) and event time in AT706 (HHMM). LH1 carries hazmat-related dates in CCYYMMDD format within 856 transactions. Both segments use inline date fields without a separate qualifier element.

X12 uses two date formats depending on the segment:

No separators. 2025-10-23, 10/23/2025, and Oct 23 2025 are all invalid.

X12 time is always 24-hour clock with no separators:

Valid examples:

Invalid examples:

DTM uses DTM01 for the qualifier. G62 uses G6201. The codes carry the same meaning in both segments. The following qualifiers appear in both:

This list covers the most common overlapping codes. Valid qualifier codes vary by transaction type and trading partner. Always check your trading partner's EDI guidelines for the exact qualifiers they accept — using a qualifier not listed in their guidelines will cause a validation error even if the code is valid X12.

When a time value in DTM03 or other time fields requires timezone context, DTM04 carries the timezone code:

DTM04 is optional in X12 but many trading partners require it. If omitted, the receiver may assume local time or reject the transaction depending on their guidelines.

Orderful generates ISA09 and ISA10 timestamps in Mountain Time. These reflect when the interchange was created by Orderful, not when the business event occurred. They are not configurable.

Time codes like ET, CT, MT, and PT refer to the fixed standard time offset, not the observed local time. During daylight saving periods, a sender in Eastern Time is actually operating at UTC-4, not UTC-5. If your trading partner is strict about UTC alignment, the safest approach is to agree on UT (UTC) as the timezone convention for all time fields — this eliminates daylight saving ambiguity entirely.

Error: Must be a time expressed in 24-hour format HHMMSSd..d or similar format validation failure on a date or time field.

Cause: The value contains separators, AM/PM indicators, an out-of-range hour or minute, or uses the wrong number of characters for the field.

Fix — correct at source (preferred): Update your source system or integration to output dates and times in the correct X12 format for the field.

Fix — Rules Engine: Use FORMATDATE to convert the value to the correct format.

Error: 035 is not a valid input or similar qualifier validation failure.

Cause: The qualifier in DTM01 is either not valid for the transaction type, or not accepted by the trading partner's guidelines.

Fix — remap the qualifier: Use a rule to replace the invalid qualifier with the correct one.

Example: Single remap

Example: Multiple remaps

Fix — remap qualifier and adjust the date: If the new qualifier represents a different point in time than the original (e.g., remapping a ship date qualifier to a delivery date qualifier), use ADDTIME or SUBTRACTTIME to calculate the correct date from the original value or another date field.

Example: Add 2 days to the original DTM02 date when remapping qualifier

Fix — add a missing qualifier with a calculated date: If the required qualifier is missing entirely, add a segment iteration in the Rules Engine with the correct qualifier and calculate the date using one of:

Example: Add a delivery date DTM (qualifier 002) calculated as ship date + 3 days

Example: Add a missing creation date DTM using current timestamp

Error: BIG01 Invoice date is out of variance with the ITD06 net due date or The invoice date is greater than system date.

Cause: Trading partners enforce business rules about the relationship between dates — for example, invoice date cannot be in the future, or net due date must be within 30 days of invoice date.

Fix — correct at source (preferred): If the date is genuinely wrong, fix it in your source system before sending.

Fix — Rules Engine (when the date can be derived): If the incorrect date can be calculated from another date already in the transaction, use ADDTIME and FORMATDATE to compute the correct value. If no source date exists in the transaction, CREATEDAT() can be used when the current date is an appropriate baseline.

Set net due date to 30 days after invoice date:

Set a missing date field to today's date:

Important: Do not use a rule to mask a date that is genuinely wrong in your source data — fix it at the source.

Symptom: Your trading partner reports that event times appear incorrect, or times in the transaction appear to precede the ISA interchange timestamp.

Cause: The timezone code in DTM04 (or equivalent time fields) does not match the convention your trading partner expects, or times are in local time while the partner expects UTC.

Fix — align on UTC with your trading partner (recommended): Agree with your trading partner to use UT (UTC) for all time fields. This eliminates timezone conversion entirely and is not affected by daylight saving transitions.

Fix — Rules Engine offset (short-term workaround): Use ADDTIME or SUBTRACTTIME to shift the time value to the correct timezone. Apply the offset to both the time field and the date field — adding hours to a late-evening time can roll the date into the next day, and the date field will not update automatically.

Example: Shift the time field (EST to UTC, +5 hours)

Shift the date field by the same offset to account for potential day rollover:

For example, a time of 2100 EST shifted by 5 hours becomes 0200 UTC the following day — without updating the date field, the transaction would carry the wrong date.

Important: Fixed-offset rules break during daylight saving transitions. A rule shifting EST (UTC-5) to UTC will be wrong during EDT (UTC-4). If your trading partner observes daylight saving, a fixed-offset rule is not a reliable long-term solution — aligning on UTC at the source is the correct fix.

Why does ISA09 use a 2-digit year when everything else uses 4 digits?
ISA is a fixed-length segment of exactly 105 characters. The 2-digit year format in ISA09 is a constraint built into the original standard and has never been updated. It is intentional and correct — do not use a 4-digit year in ISA09.

Does every DTM segment need a timezone code in DTM04?
Not by the base X12 standard, but many trading partners require it in their guidelines. Check your trading partner's requirements. When in doubt, including LT or UT is safer than omitting it.

Can I send the same qualifier twice in one transaction?
It depends on the segment's loop structure in the transaction spec. Some loops allow multiple DTM iterations with different qualifiers. Check the X12 specification for your transaction type and version.

My source system outputs dates with slashes (10/23/2025) — do I need to fix this at the source?
Yes, or use a FORMATDATE rule to strip the separators and reformat from YY/MM/DD to ?YYYYMMDD. Both are valid approaches — the Rules Engine fix is reliable for format-only issues.

What is the safest timezone approach for EDI?
Use UTC (UT) for all time fields and agree on this with your trading partner upfront. UTC has no daylight saving transitions and eliminates ambiguity about what time an event occurred.