FHIR dateTime carries variable precision. A UI that formats every dateTime as "July 11, 2026 2:30 PM" is a UI that lies when the underlying value is "2026-07-11" (no time). Users read that and assume 2:30 PM was recorded when it was not. Getting the display right is a specific responsibility that lives on the rendering layer. The site's FHIR timestamp inspector surfaces the actual precision. For the wider FHIR framing, more on healthcare integration has more.
What Precision Actually Means
"2026"— the year"2026-07"— the month"2026-07-11"— the day"2026-07-11T14:30:00Z"— the second"2026-07-11T14:30:00.123Z"— the millisecond
Each carries a different implied range of possible instants. Displaying at a higher precision than the value carries is a lie.
For the partial-date framing, partial dates: birthDate is not always a full date is the entry.
Format At The Precision Provided
"2026"→ "2026" or "in 2026""2026-07"→ "July 2026""2026-07-11"→ "July 11, 2026""2026-07-11T14:30:00Z"→ "July 11, 2026 at 2:30 PM UTC"
Simple rule. Every UI that shows FHIR temporal values should follow it.
Locale And Format
- US: "July 11, 2026" or "07/11/2026"
- UK: "11 July 2026" or "11/07/2026"
- ISO everywhere: "2026-07-11"
Every locale wants its own format. The precision rule is the same; the surface format differs.
For the internationalization side, internationalization for FHIR dates in a global product is the entry.
Timezones In Display
When the value has a timezone, the UI has three options:
- Render in UTC
- Render in the value's original timezone
- Render in the viewer's timezone
Rendering in UTC is simplest and least useful. Rendering in the viewer's timezone is most helpful for the user. Rendering in the original timezone preserves clinical context.
Pick per the workload. For clinical audit contexts, original zone often wins. For patient-facing UIs, viewer's zone.
For the timezone deep dive, timezones in clinical timestamps and where they hide is the entry.
Never Guess The Zone
If the value has no timezone (partial date, dateTime with only date component), do not render a time. Do not silently assume UTC or local.
The value did not have a time. The UI must not invent one.
Relative Rendering
- "2 hours ago"
- "yesterday"
- "3 weeks ago"
Relative rendering is useful for recency but hides absolute precision. Users lose the ability to correlate with other timestamps.
Rule: show relative + absolute on hover, or show relative only when the value is within some recency threshold.
Format For Screen Readers
Screen readers do not always parse "07/11/2026" correctly. Prefer semantically-rich formats: .
The element with a machine-readable datetime attribute is what screen readers rely on for correct pronunciation.
The Component Layer
Every UI should have a
- Accepts the raw FHIR string
- Detects precision
- Renders at that precision only
- Handles locale and timezone
Centralizing the logic prevents the "each screen formats differently" drift.
The Short Version
Detect precision from the source string. Render at that precision. Never invent time components. Prefer semantic HTML. Centralize in a component. Handle locale and timezone per workload.
Sources
- HL7 canonical R4 datatypes chapter covering temporal - HL7 canonical R4 datatypes chapter covering temporal precision
