- All Implemented Interfaces:
- Primitive, Type, Visitable, Serializable
public class TSComponentOne
Note: The class description below has been excerpted from the Hl7 2.4 documentation. Sectional
references made below also refer to the same documentation.
Contains the exact time of an event, including the date and time. The date portion of a time stamp follows the rules of a
date field and the time portion follows the rules of a time field. The time zone (+/-ZZZZ) is represented as +/-HHMM
offset from UTC (formerly Greenwich Mean Time (GMT)), where +0000 or -0000 both represent UTC (without offset).
The specific data representations used in the HL7 encoding rules are compatible with ISO 8824-1987(E).
In prior versions of HL7, an optional second component indicates the degree of precision of the time stamp (Y = year, L
= month, D = day, H = hour, M = minute, S = second). This optional second component is retained only for purposes of
By site-specific agreement, YYYYMMDD[HHMM[SS[.S[S[S[S]]]]]][+/-ZZZZ]^ may be used
where backward compatibility must be maintained.
In the current and future versions of HL7, the precision is indicated by limiting the number of digits used, unless the
optional second component is present. Thus, YYYY is used to specify a precision of "year," YYYYMM specifies a
precision of "month," YYYYMMDD specifies a precision of "day," YYYYMMDDHH is used to specify a precision of
"hour," YYYYMMDDHHMM is used to specify a precision of "minute," YYYYMMDDHHMMSS is used to specify a
precision of seconds, and YYYYMMDDHHMMSS.SSSS is used to specify a precision of ten thousandths of a second.
In each of these cases, the time zone is an optional component. Note that if the time zone is not included, the timezone
defaults to that of the local time zone of the sender. Also note that a TS valued field with the HHMM part set to "0000"
represents midnight of the night extending from the previous day to the day given by the YYYYMMDD part (see example
below). Maximum length of the time stamp is 26. Examples:
1:01:59 on July 4, 1976 in the Eastern Standard Time zone (USA).
1:01:59 on July 4, 1976 in the Eastern Daylight Saving Time zone (USA).
Midnight of the night extending from July 4 to July 5, 1988 in the local time zone of the sender.
Same as prior example, but precision extends only to the day. Could be used for a birthdate, if the time of birth is
1:01:59 on October 4, 1998 in Amsterdam, NL. (Time zone=+0100).
The HL7 Standard strongly recommends that all systems routinely send the time zone offset but does not require it. All
HL7 systems are required to accept the time zone offset, but its implementation is application specific. For many
applications the time of interest is the local time of the sender. For example, an application in the Eastern Standard Time
zone receiving notification of an admission that takes place at 11:00 PM in San Francisco on December 11 would prefer
to treat the admission as having occurred on December 11 rather than advancing the date to December 12.
Note: The time zone [+/-ZZZZ], when used, is restricted to legally-defined time zones and is represented in HHMM
One exception to this rule would be a clinical system that processed patient data collected in a clinic and a nearby hospital
that happens to be in a different time zone. Such applications may choose to convert the data to a common
representation. Similar concerns apply to the transitions to and from daylight saving time. HL7 supports such requirements
by requiring that the time zone information be present when the information is sent. It does not, however, specify which of
the treatments discussed here will be applied by the receiving system.
- Neal Acharya
- See Also:
- Serialized Form