Overview
DTM carries precision as well as date and time
The HL7 v2 DTM data type represents a point in time using a 24-hour clock. Its digits are ordered from the broadest unit to the most precise: year, month, day, hour, minute, second and fractional second. The number of populated characters, excluding the time-zone suffix, states the precision of the value.[1]
20260729143000+0100This value means 14:30:00 on 29 July 2026 at an offset of one hour ahead of Coordinated Universal Time (UTC). It identifies the same instant as 13:30:00 UTC.
Do not read DTM as an ISO 8601 string. The concepts are similar, but HL7 v2 uses a compact format without hyphens or colons and expresses UTC as an offset such as +0000. A trailing Z is not part of the DTM syntax.
DTM format
Each additional part increases the stated precision
The current HL7 v2 definition gives the format as YYYY[MM[DD[HH[MM[SS[.S[S[S[S]]]]]]]]][+/-ZZZZ].[1] Square brackets describe optional trailing parts; they are not transmitted.
| Value | Precision | Meaning |
|---|---|---|
2026 | Year | An unspecified time within 2026. |
202607 | Month | An unspecified time in July 2026. |
20260729 | Day | 29 July 2026, with no time of day stated. |
2026072914 | Hour | An unspecified time within the 14:00 hour. |
202607291430 | Minute | An unspecified second within 14:30. |
20260729143000 | Second | 14:30:00 in the applicable local time zone. |
20260729143000.250 | Millisecond | 14:30:00.250 in the applicable local time zone. |
20260729143000+0100 | Second with offset | 14:30:00 at UTC+01:00. |
HL7 v2.5.1 uses the same central DTM structure and permits fractional precision to ten-thousandths of a second.[2] The applicable interface profile can restrict a field to a particular precision even when the base data type permits a shorter or longer form.
Missing parts are unknown, not zero
Changing 20260729 to 20260729000000 adds a time that the sender did not supply. The first value has day precision; the second states an exact local time of midnight. That conversion can create false ordering, produce a date shift after UTC conversion, or make an unknown birth time look recorded.
Message defaults
MSH-7 can establish the message time zone
MSH-7 contains the date and time when the sending system created the message. In the current HL7 v2 definition, an offset in MSH-7 becomes the default time zone throughout that message.[3]
MSH|^~\&|WARDAPP|MAIN|RESULTS|MAIN|20260729143000+0100||ORU^R01^ORU_R01|MSG000401|P|2.5.1If another DTM field contains a time but no explicit offset, the receiver can interpret it using the MSH-7 default when the agreed version and profile apply that rule. If MSH-7 also omits the offset, the base DTM rule defaults the value to the sender's local time zone.[1]
This still requires an interface agreement. A receiver cannot safely guess the sender's local zone from its own server settings, an IP address or a facility name. Record the expected sender time zone and whether individual fields can override it with their own offsets.
Different timestamp fields describe different events
MSH-7 is the message creation time. It is not automatically the admission, order, specimen collection, observation or result-release time. For example, OBR-7 represents the clinically relevant observation time, while OBX-14 can identify the physiologically relevant time for an individual observation.[4][5]
Replacing every clinical timestamp with MSH-7 may produce valid DTM values but incorrect event chronology. Map each source field by meaning before applying a common conversion routine.
UTC conversion
The offset sign states how local time relates to UTC
The DTM suffix is a numeric offset in +/-HHMM form. A positive offset means the local time is ahead of UTC, so the offset is subtracted to obtain UTC. A negative offset means the local time is behind UTC, so its magnitude is added.
| HL7 DTM | Calculation | UTC instant |
|---|---|---|
20260729143000+0100 | 14:30 minus 1 hour | 2026-07-29T13:30:00Z |
20260729143000-0400 | 14:30 plus 4 hours | 2026-07-29T18:30:00Z |
20260729143000+0000 | No change | 2026-07-29T14:30:00Z |
A common defect is to add a positive offset or subtract a negative one. The result is displaced by twice the intended difference. Parse the full signed suffix as one value and verify the conversion with a known example before applying it to production mappings.
+0000 and -0000 need version-aware handling
For implementations before HL7 v2.9, +0000 and -0000 both represent UTC without an offset distinction. Starting with v2.9, +0000 represents a known civil offset of zero, while -0000 represents UTC when the local offset is not known.[1] Most integrations only need the instant, but software that preserves the source's offset knowledge should follow the declared HL7 version.
Daylight saving
A numeric offset belongs to one timestamp, not an entire location
An offset such as +0100 identifies the relationship to UTC for that DTM value. It does not carry a named regional time zone or its historical and future daylight-saving rules. Two timestamps from the same facility can legitimately use different offsets at different times of the year.
When the source provides an offset, preserve and use it for that instant. When the source provides only local time, use the sender's agreed regional time zone and resolve the offset for the event date, not the integration server's current offset. A fixed +0100 configuration throughout the year will be wrong for locations that change between standard time and daylight-saving time.
Repeated and missing local times need an explicit rule
When clocks move backwards, one local clock value can occur twice with different offsets. When clocks move forwards, some local values do not occur. A DTM carrying an explicit offset distinguishes repeated times; a local value without one may remain ambiguous.
Do not silently select an offset when the instant affects ordering, duration or event matching. Define whether the sender must include an offset, whether the message is rejected, or whether the original local value is retained for later correction.
Worked example
Keep message creation, patient date and observation time separate
This synthetic ORU message contains three different temporal concepts:
MSH|^~\&|WARDAPP|MAIN|RESULTS|MAIN|20260729143000+0100||ORU^R01^ORU_R01|MSG000401|P|2.5.1
PID|1||MRN100^^^MAIN^MR||SAMPLE^ALEX||19880705
OBR|1|ORD100|RES100|718-7^Haemoglobin^LN|||20260729141000+0100
OBX|1|NM|718-7^Haemoglobin^LN||135|g/L|120-160|N|||F|||20260729141000+0100| Field | Value | Correct interpretation |
|---|---|---|
MSH-7 | 20260729143000+0100 | The message was created at 13:30:00 UTC. |
PID-7 | 19880705 | A date of birth with day precision. No time or UTC conversion is implied. |
OBR-7 | 20260729141000+0100 | The observation began at 13:10:00 UTC. |
OBX-14 | 20260729141000+0100 | The individual result refers to the same physiologically relevant observation instant. |
The observation predates message creation by 20 minutes. Substituting MSH-7 for OBR-7 or converting PID-7 as midnight would change the meaning even though every resulting value could still be stored successfully.
Common failures
Timestamp defects and their observable effects
| Symptom | Likely cause | What to verify |
|---|---|---|
| Every event is one or several hours early | The receiver assumed its own local zone or applied the offset in the wrong direction. | The raw suffix, sender zone, parsed offset and UTC result. |
| The time is shifted twice | An integration engine normalised to UTC and downstream code converted the already-normalised value again. | The value and zone at each transformation boundary. |
| A date of birth moves to the previous day | A day-precision value was padded to midnight and converted to UTC. | Original DTM length and destination date type. |
| Summer messages are one hour wrong | A fixed offset was used instead of the regional rules for the event date. | Event date, named sender zone and resolved offset. |
| One repeated clock time maps inconsistently | The local value occurred twice during a daylight-saving transition and carried no offset. | Whether the source can send an explicit suffix. |
| A parser rejects a value ending in Z | An ISO 8601 timestamp was placed in a DTM field without conversion to HL7 syntax. | The interface's declared data type and exact transmitted characters. |
| Fractional seconds disappear | The parser, destination column or formatting step supports less precision. | Source fractional length, parser type and storage scale. |
| Clinical event order follows message order | MSH-7 was used instead of the appropriate event timestamp. | Field semantics for admission, collection, observation and result release. |
| A value without an offset changes between servers | Each environment applies a different default local time zone. | Runtime time-zone configuration and MSH-7 default. |
Troubleshooting
A repeatable timestamp investigation
- Capture the original DTM string. Do not start with a formatted screen value or a database value that may already be converted.
- Identify the field and its meaning. Separate message creation, admission, order, collection, observation and result-release times.
- Record the declared precision. Count the digits before any fractional part or offset and note whether missing parts are genuinely unknown.
- Extract the explicit offset. If the field has none, inspect MSH-7 and the interface agreement for the sender's default zone.
- Convert one value manually. Apply the signed offset to a known timestamp and compare it with the parser result.
- Trace every representation. Record the raw HL7 value, parsed local value, offset, UTC value, database type and display zone.
- Check daylight-saving rules at the event date. Do not use the server's current offset for a historical or future event.
- Look for a second conversion. Confirm whether the integration engine, API serializer, database driver or user interface already normalises times.
- Test date-only and ambiguous values separately. They need different rules from complete timestamps with offsets.
- Retest with synthetic boundary cases. Include UTC, positive and negative offsets, a date-only value, fractional seconds and both sides of a daylight-saving change.
Use the HL7 Message Formatter & Viewer to locate DTM fields in a synthetic message, then use the HL7 Message Diff tool to compare the raw values before and after a mapping change.
Checklist
What to define in an HL7 timestamp interface
- The HL7 version, message profile and expected data type for each date or time field.
- The required or permitted precision for each field.
- Whether offsets are mandatory and whether MSH-7 supplies the message default.
- The sender's named regional time zone when offset-free local values are allowed.
- How date-only and other partial-precision values map to the destination.
- Whether the integration layer stores local time, UTC, the original offset or all three.
- Which component is responsible for UTC normalisation.
- How daylight-saving gaps and repeated local times are handled.
- The supported fractional-second precision in parsers and database columns.
- Whether the original DTM value is retained for audit and troubleshooting without retaining unnecessary patient data.
FAQ
Frequently asked HL7 timestamp questions
Is an HL7 DTM without an offset UTC?
No. The DTM rule treats a value without an offset as local to the sender. MSH-7 may provide the default time zone for the message. An interface can agree to send all values in UTC, but that agreement should be explicit and testable.
Can I append Z to show UTC?
Not in a DTM field. Use the HL7 offset form +0000 for a known zero offset. A trailing Z belongs to other date-time syntaxes and can cause an HL7 parser to reject the value.
Should 20260729 be treated as midnight?
No. It has day precision and does not state a time. Store it as a date or preserve its precision rather than inventing 000000 and converting that value to UTC.
Should every timestamp be converted to UTC?
UTC is useful for comparing complete instants across systems, but conversion must preserve the original meaning, precision and offset. Date-only or otherwise partial values should not be forced into exact UTC instants.
Why is the timestamp correct in test but wrong in production?
The environments may use different operating-system time zones, daylight-saving rules, database column types or parser defaults. Compare the raw DTM and each intermediate representation rather than only the final display.
Primary references
HL7 Version 2 date and time sources
- HL7 Version 2+: DTM Date/Time Data Type: current DTM syntax, variable precision, UTC offsets, default sender time zone and version-specific
+0000/-0000behaviour. - HL7 Version 2.5.1, Chapter 2.A: Data Types: DTM structure, precision, offset recommendations and examples for a widely deployed HL7 v2 version.
- HL7 Version 2+: MSH Message Header Segment: MSH-7 meaning and its message-wide default time-zone rule.
- HL7 Version 2+: OBR Observation Request Segment: the clinically relevant meaning of OBR-7 and related observation times.
- HL7 Version 2+: OBX Observation/Result Segment: OBX-14 as the physiologically relevant date and time for an individual observation.
Local implementation guides and interface agreements remain authoritative for required precision, offset usage, default zones, storage behaviour and field-specific mapping.