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.
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.
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 – 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)