DE7, transmission date and time, is the moment the message entered the network — not the moment the transaction happened. The specifications require it in Coordinated Universal Time. Mastercard's documentation states it as UTC; Visa's says GMT, which for this purpose is the same instant.
So DE7 is the one field in the message you can compare across acquirers, across countries and across a whole day's traffic without knowing anything about where the terminal was. If you need a single ordering of events, this is the field to key on.
Two things about it that catch people. It carries no year — the format is
MMDDhhmmss, ten digits — so a message that crosses 1 January is ambiguous on its own
and has to take the year from context. And it is checked against the network's own clock: a DE7
too far from the receiving system's time is rejected rather than accepted and corrected, which is
why an endpoint with a drifting clock starts failing in a way that looks like a routing problem.
DE12, local transaction time, is the time at which the transaction took place at the point of service. DE13, local transaction date, is the matching date. Both are the acceptor's wall clock.
The field carries the reading and nothing else. There is no offset, no zone identifier, no
indication of whether daylight saving was in effect. A DE12 of 143000 means half past
two in the afternoon somewhere, and the message does not tell you where.
That has a hard consequence: you cannot convert DE12 to UTC using only the message. To do it you need to know the terminal's timezone, which has to come from somewhere else — your own terminal estate records, the acquirer's, or the merchant's country as a rough proxy. And you cannot order two transactions from different acquirers by comparing their DE12 values, because the two readings are not on the same clock.
It is tempting to describe DE12 as a timezone-free time, and that framing leads people wrong. DE12 has a timezone — the acceptor's. The transaction happened at a definite instant in a definite place. What is missing is not the timezone; it is any statement of it inside the message.
The distinction matters because it tells you what kind of problem you have. A genuinely timezone-free value would be unresolvable in principle. DE12 is resolvable in principle and unresolved in practice: the information exists, it just lives in your terminal records rather than in the message. Anything that turns DE12 into an absolute instant is a join against data you hold, not a calculation on the field.
The same reading applies to the answer you will sometimes see that Mastercard "requires UTC for DE12". That requirement is about DE7. Conflating the two produces timestamps that are wrong by whatever the terminal's offset happens to be, which in reconciliation shows up as a small population of transactions that appear to have been authorized before they were attempted.
DE12 is not the same shape everywhere:
| Where | DE12 | DE13 |
|---|---|---|
ISO 8583:1987 — authorization, 0100 and friends | hhmmss, six digits, time only | MMDD, the local date |
1993 onward — clearing, 1240 and friends | YYMMDDhhmmss, twelve digits, date and time | redefined; no longer the local date |
Both forms are still local time. The change is the width and whether the date rides along, not the clock. A parser configured for one edition reading the other will decode a plausible-looking wrong answer rather than failing, which is the usual way this bites. Which fields move between the two message families is set out in authorization versus clearing.
Because DE7 and DE12 are on different clocks, a transaction near midnight can legitimately carry two different dates in the same message. A purchase at 23:40 local in a zone eight hours ahead of UTC has a local date of one day and a transmission date of the day before. Neither field is wrong.
Which one your reports should use depends on what the report is for, and picking without deciding is where reconciliation breaks. A merchant-facing statement that says a sale happened on a day the merchant was closed is usually DE7 being used where DE12 was meant. A count of a day's traffic that does not match the network's is usually the reverse.
And there are more clocks in the same message than these two. DE15, settlement date, is neither local nor the transmission moment — it is the day the scheme will settle the item, set by the scheme's own cycle, and it can be days later. DE16 conversion date and DE17 capture date are each set by whoever performed that step. Five date and time fields in one message, four different owners: the terminal, the network, the scheme and the capturing system. Treating any of them as interchangeable is the root of a whole family of off-by-a-day defects.
→ Decode a message and see its time fields