DE7, transmission date and time, is the moment the message entered the network β not the moment the transaction happened. Plenty of references will tell you DE7 is simply UTC. That holds for Mastercard. It does not hold for Visa.
Mastercard says must: the date and time must be expressed in Coordinated Universal Time (UTC). It is a hard requirement, so DE7 on an MC link can be read as UTC directly.
Visa says can: GMT may be used β may, not must. The field edits for Field 7 check only MM = 01-12, DD = 01-31, hh = 00-23, mm = 00-59, ss = 00-59, plus the maximum day count for the month. Not one of them looks at a time zone. On top of that Field 7 is a retain-and-return field β the receiving client saves the value and returns it in the response β and V.I.P. passes it through without normalising it.
Put those together and an acquirer filling DE7 with its own local time is fully compliant and will not be rejected. We have seen this in production: a Chinese acquirer (f032 = 405976, an f043 merchant name starting with WEIXIN*, f019 = 156) sends DE7 in Beijing time, and the issuer side receives a +8 value.
So the accurate statement is that the time zone of Visa's DE7 is the acquirer's choice, and it can differ between acquirers for the same issuer. If you want to order events by DE7 or compare across acquirers, an MC link is safe; on a Visa link, confirm what that acquirer actually sends first, or key on something else.
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