TL;DR: ISO 8601 writes dates YYYY-MM-DD and times in 24-hour form, often with timezone offset: 2026-03-15T14:30:00-05:00. APIs and logs use it to avoid US/EU date ambiguity.
Date before time
Big-endian date 2026-03-15 not 03/15/2026—eliminates March vs May confusion in multinational teams.
T separator
Literal T between date and time in combined timestamp—programmers grep logs reliably.
Timezone offsets
Trailing -05:00 or Z for UTC—never orphan local time without offset in API contracts.
Duration vs datetime
PT2H30M means duration two hours thirty minutes—not clock 0230—read spec symbol P vs time colon syntax.
JSON REST payloads
Field “scheduledAt”:”2026-07-04T090000Z”—client parses to local display; store canonical UTC internally.
Spreadsheet import
CSV ISO strings convert cleaner than mixed US date + 12h time columns from legacy exports.
Medical device logs
FDA submissions expect traceable timestamps—ISO 8601 satisfies audit trail readability globally.
Comparison to military HHMM
Military chart gives time-of-day; ISO wraps full calendar context—use both layers in travel ops planning.
Validate samples
Convert local 1430 on date to ISO string in script; human spot check against converter output for hour portion.
Documentation for vendors
RFP requires “all timestamps ISO 8601 UTC”—single sentence saves integration meetings.
ISO date big-endian
2026-03-15 eliminates US/EU slash ambiguity in multinational API contracts.
T separator in logs
grep-friendly combined datetime—devops standard across regions.
Offset trailing -05:00
Never orphan local time without offset in JSON payloads.
Duration PT2H30M vs clock
P prefix means duration not time-of-day—read spec carefully.
RFP single sentence
Require ISO 8601 UTC timestamps—saves integration meetings.
Payload instant 2026-04-02T22:15:00-04:00
The string 2026-04-02T22:15:00-04:00 is one instant: 2 April 2026, 22:15, fifty-nine seconds not included, in a zone four hours behind UTC. 22:15 is a quarter past ten in the evening on the local face of that offset. The T separates the date from the time so a parser does not have to guess. A human note can say “22:15 local, offset minus four.” The payload should stay in the standard form. Rewriting it as “10:15 PM EST” in the stored field breaks the parser and invites a daylight-saving argument the offset had already settled.
If you must show a friendly form on a dashboard, derive it. Do not replace the stored string. The derivation for this example is “2 Apr 2026, 22:15, offset −04:00.” Keep the offset visible. A friendly form that drops the offset and keeps 22:15 will be wrong for a reader in another zone, and they will still think they are looking at local time because 22:15 looks local.
Duration PT2H15M is not a clock stamp
A duration of two hours and fifteen minutes may appear as PT2H15M. It is not 0215 and it is not 1415. It is a length. If a ticket says the job starts at 2026-04-02T22:15:00-04:00 and lasts PT2H15M, the end is 00:30 on 3 April in that same offset. Compute the end once and store it as another instant. Do not store the duration in the time column. A column that mixes PT2H15M and 22:15 will sort as text and mean nothing.
Vendor sentence that names the offset once
In a contract sentence, you may write “22:15 with offset −04:00 on 2026-04-02, equivalent to 02:15 UTC on 2026-04-03.” Check that equivalence: 22:15 plus four hours crosses midnight and becomes 02:15 the next day. If your sentence says the same date on both sides, the sentence is wrong. The payload’s offset did the hard part. The prose must not undo it for the sake of a shorter line.
Import check that refuses a bare 10:15 PM
A spreadsheet import of this feed should reject a cell that says 10:15 PM if the source column was ISO. The rejection is a feature. Someone “helpfully” converted the sample and dropped the date. The sample row you keep for testing is exactly 2026-04-02T22:15:00-04:00. If that row displays as a date in 2026 and a time of 22:15 in the stated offset, the import is alive. If it displays as 10:15 PM with no date, the import is a formatting accident. Do not accept the accident because the hour feels familiar.
Dashboard derivation that still shows the offset
The friendly dashboard may say “2 Apr 2026, 22:15” only if the offset remains on the same card. A card that drops −04:00 has thrown away the part that made the instant unique. Put the offset in the same type size as the hour. People skip gray microcopy. They do not skip a number that looks like part of the time. If the designer insists on hiding it, the dashboard is not friendly. It is local-only, and it must be labeled local-only so a remote reader does not treat 22:15 as their evening.
Second fixture row at 2026-11-01T01:30:00-04:00
Add a second test instant that falls near a clock change, not only the April example. 2026-11-01T01:30:00-04:00 is a different month and a repeated-hour season in zones that fall back. Your importer must store it without turning it into “1:30” with no offset. If the only fixture is 2026-04-02T22:15:00-04:00, you have tested a spring evening and nothing else. The November row is how you notice a parser that assumes every 01:30 is unique.
Document the expected UTC equivalent next to the fixture, computed by hand once. If the code’s UTC does not match the note, the code loses. Do not update the note to match the code until a second person agrees the note was wrong. Fixtures that follow the code are souvenirs. Fixtures that the code must meet are tests.