The article Moments in time in CDA, overviews the format used to represent a “timestamp” in CDA documents. It also presents several examples of timestamps. For example, the representation of August 22, 2013 6:15pm in a CDA XML element named time (refer to The time element, for additional information) would be:

<time value='201308221815' />

This same timestamp format is used throughout CDA to represent a point in time – including the endpoints of time intervals, as explained in Time intervals in CDA.

The Problem With Time-Zones

To represent time-zones, the timestamp format uses ±ZZzz at the end to express the time-zone as an offset from UTC. For example, this timestamp syntax represents
December 1, 2013 8am, Los Angeles Time (PST):

<time value='201312010800-0800' />

Now consider an application that has to take the data in a CDA document and display it in a human-readable format (on screen, in a printed report, etc.) that needs to translate the attribute value ‘201312010800-0800′.

It of course would not be able to display “Los Angeles” – because -0800 could represent any geographical location where the time was 8 hours before UTC.

It probably could safely assume “PST” because that is almost the only practically used time-zone name that is 8 hours ahead of UTC. But if the time indicated was 3 hours ahead of UTC, that might be the time-zone in Nairobi, Baghdad, or Minsk.

So, the translation from human readable time-zone… to the time-zone format representation in CDA… back to human-readable form… is unlikely to result in the human-readable time-zone display that was present at the start.

Daylight Savings Time
Moreover, when considering Daylight Savings Time, absent a date, the time 0830-0700 might be 8:30 am in California with Daylight Savings Time in the summer or 8:30am Mountain Time in the winter.

Even if the date is present, the logic required to correctly select the time-zone based on the ±ZZzz in the timestamp format is non-trivial. Different time-zones switch into and out of Daylight Savings Time on different days – and in many time-zones the dates of those changes were at different historical times.

Rendering CDA with a Stylesheet
The software used to render a CDA document in human-readable format can potentially use various software language functions and libraries to assist with this translation from “UTC offset” to “time-zone display name”.

However, when using XML Stylesheets to render a CDA document – which is the most common rendering mechanism used for CDA today, the translation is especially challenging. The cda.xsl XML Stylesheet that is included in the HL7 CDA downloadable package of materials, does a very simplistic mapping of UTC offsets to displayed time-zone names. So, for example, the UTC offset -0800 is always translated to PST – even in the summer months when it would correctly be MDT (Mountain Daylight Time).

Other CDA PRO Know Articles Referenced In This Article