Timezones are qualified with an hour and minute offset from GMT and not with a flag indicating daylight savings time.
There is no method or technique in HL7 to indicate if the time given in the message is daylight savings time or not.
I previously wrote about the challenges of time zone qualification within an HL7 message and, more broadly, the general challenges when two systems attempt to share a date and time over an interface. As previously noted, the HL7 standard mandates that if a date and time will be qualified with a timezone, the qualification is provided as a numeric offset from GMT/UTC given in hours and minutes.
There is no method or technique in HL7 to indicate if the time given in the message is “daylight savings time or not.” The reason no such flag exists is that the offset provided in a qualified date/time is not the acronym of the timezone itself (e.g., EST for Eastern Standard Time or EDT for Eastern Daylight Time), but rather is a hour and minute offset from GMT.
In our HL7 training classes we use the following real world example to make the case for the need to qualify dates and times:
Example of Daylight Savings Time (DST) in the US
Real world example with birth of twins:
- Baby A arrives 11/4/2007 at 1:32 a.m. EDT
- 34 minutes pass
- Baby B arrives at 11/4/2007 1:06 a.m. EST
In HL7 speak, no problem!:
- Baby A’s date/time of birth: 200711040132-0400
- Baby B’s date/time of birth: 200711040106-0500
This really happened at WakeMed Cary Hospital, Cary, NC.
- Daylight-Saving Causes Twin Arrival Pickle: Twins born 34 minutes apart while daylight savings time changes
- HL7 Time Zone Qualification: Both HL7 V2.x and V3.x support complex date structures
- HL7 Dates and Times: Clock Skew and lack of time zones hamper HL7 integration
Latest posts by Dave Shaver (see all)
- HL7 ADT Q&A with Dave Shaver - July 2, 2014
- Health Standards Community Membership Archetypes: Who uses HL7? - August 6, 2013
- Note from the Field: Meditech 6.0 HL7 Integration - September 6, 2011