Versions Compared


  • This line was added.
  • This line was removed.
  • Formatting was changed.

A proposal is in the works to extend the DTM data type to include the actual time zone.

The current DTM data type YYYY[MM[DD[HH[MM[SS[.S[S[S[S]]]]]]]]][+/-ZZZZ] refers to 'ZZZZ' as Time zone,

but it actually specifies the offset from UTC.

Proposal One

Extend the V2 DTM data type by adding a CNE which contains the reference to IANA timezone code for the timezone offset per BCP 175.


Example :20180523155001+0000 ^GB ^Great  Britain ^tzdb2018e

Further investigation found that GB had been replaced by Europe/London which would make it 20180523155001+0000 ^Europe/London ^Europe/London ^tzdatabase

While this would convey the data/concept, it would not be easily computable.

Proposal Two

Since we have a number of implementors who are doing V2-to-FHIR conversions, I propose the following

Extend the V2 DTM data type by adding the W3C/ISO definition as the second component.


YYYY[MM[DD[HH[MM[SS[.S[S[S[S]]]]]]]]][+/-ZZZZ]^ yyyy-mm-ddThh:mm:ss[.SSS]TZD

    • yyyy – 4 digit year
    • mm - numeric month (01-12)
    • dd – 2 digit day
    • T – constant
    • hh – 24 hour clock
    • mm – 2 digit minute
    • ss – 2 digit second
    • [.SSS – sub-second up to millisecond precision] - optional
  • TZD - constant
  • ·         Z (used when the date/time is expressed completely in zulu or UTC date/time)
  • ·         Use only if there is no need to know the local time representing where the field applies, or can be derived from other context where relevant.
  • ·         +/-hh:mm (use a '+' or '-' when the date/time is expressed as a wallclock date/time with a time offset against zulu or UTC date/time)

View file