A data type containing date and/or time information. This data type is a placeholder, as various platforms have differing built-in date-time data types. This data type is intended to handle both precise dates and imprecise dates (e.g., just a year), which would likely be implemented using different data types. Therefore, it is anticipated that this data type will be replaced by a different data type when transforming to a particular implementation platform.
Note that the FHIM has one data type that can be used to hold a date, a date-and-time, or just a time. In contrast FHIR has four data types: date, dateTime, time, and instant. The FHIM currently does not distinguish among the levels of precision that might be used in actual implementations, but leaves the datatype broad to handle all possible use cases. The FHIM PointInTime data type is most closely aligned with the FHIR dateTime data type.
"A date, or partial date (e.g. just year or year + month) as used in human communication. There is no time zone. Dates SHALL be valid dates" - HL7 FHIR, date
"A date, date-time or partial date (e.g. just year or year + month) as used in human communication. If hours and minutes are specified, a time zone SHALL be populated. ... Dates SHALL be valid dates…." - HL7 FHIR, dateTime
"A time during the day, with no date specified (can be converted to a Duration since midnight). … A time zone [is not allowed]." - HL7 FHIR, time
"An instant in time - known at least to the second and always includes a time zone. Note: This is intended for precisely observed times (typically system logs etc.), and not human-reported times - for them, use date and dateTime. instant is a more constrained dateTime" - HL7 FHIR, instant

Attributes
String	literal	"TS literals are simple calendar expressions ... [which] conform to the constrained ISO 8601... Western calendar expressions begin with the 4-digit year; followed by the 2-digit month of the year; followed by the 2-digit day of the month; followed by the 2-digit hour of the day (beginning with zero); and so forth. For example, '200004010315' is a valid expression for April 1, 2000, 3:15 AM. A calendar expression can be of variable precision, omitting parts from the right. For example, '20000401' is precise only to the day of the month. The least defined calendar period (i.e. the second) may be written as a REAL, with the number of integer digits specified, followed by the decimal point and any number of fractional digits. For example, '20000401031520.34' means April 1, 2000, 3:15 and 20.34 seconds. When other calendars are used in the future, a prefix 'GREG:' can be placed before the western (Gregorian) calendar expression to disambiguate from other calendars. Each calendar shall have its own prefix. However, the western calendar is the default if no prefix is present. In the modern Gregorian calendar (and all calendars where time of day is based on UTC), the calendar expression may contain a time zone suffix. The time zone suffix begins with a plus (+) or minus (-) followed by digits for the hour and, for non UTC times, minute cycles. UTC is designated as offset '+00' or '-00'; the ISO 8601 and ISO 8824 suffix 'Z' for UTC is not permitted." - HL7 V3

 literal

Public String literal

"TS literals are simple calendar expressions ... [which] conform to the constrained ISO 8601... Western calendar expressions begin with the 4-digit year; followed by the 2-digit month of the year; followed by the 2-digit day of the month; followed by the 2-digit hour of the day (beginning with zero); and so forth. For example, '200004010315' is a valid expression for April 1, 2000, 3:15 AM. A calendar expression can be of variable precision, omitting parts from the right. For example, '20000401' is precise only to the day of the month. The least defined calendar period (i.e. the second) may be written as a REAL, with the number of integer digits specified, followed by the decimal point and any number of fractional digits. For example, '20000401031520.34' means April 1, 2000, 3:15 and 20.34 seconds. When other calendars are used in the future, a prefix 'GREG:' can be placed before the western (Gregorian) calendar expression to disambiguate from other calendars. Each calendar shall have its own prefix. However, the western calendar is the default if no prefix is present. In the modern Gregorian calendar (and all calendars where time of day is based on UTC), the calendar expression may contain a time zone suffix. The time zone suffix begins with a plus (+) or minus (-) followed by digits for the hour and, for non UTC times, minute cycles. UTC is designated as offset '+00' or '-00'; the ISO 8601 and ISO 8824 suffix 'Z' for UTC is not permitted." - HL7 V3

Constraints:

Properties:

Aggregation	None
Alias
Association
Association End
Class	«TS» PointInTime
Datatype
Default
Default Value
Is Composite	false
Is Derived	false
Is Derived Union	false
Is Leaf	false
Is Ordered	false
Is Read Only	false
Is Static	false
Is Unique	true
Keywords
Lower	1
Lower Value	(1)
Multiplicity	1
Name	literal
Name Expression
Namespace	«TS» PointInTime
Opposite
Owner	«TS» PointInTime
Owning Association
Owning Template Parameter
Qualified Name	FHIM::Datatypes::PointInTime::literal
Stereotype
Template Parameter
Type	String
Upper	1
Upper Value	(1)
Visibility	Public

• A quantity specifying a point on the axis of natural time. A point in time is most often represented as a calendar expression. Semantically, however, time is independent from calendars and best described by its relationship to elapsed time (measured as a physical quantity in the dimension of time.) A point in time plus an elapsed time yields another point in time. Inversely, a point in time minus another point in time yields an elapsed time. As nobody knows when time began, a point in time is conceptualized as the amount of time that has elapsed from some arbitrary zero-point, called an epoch. Because there is no absolute zero-point on the time axis natural time is a difference-scale quantity, where only differences are defined but no ratios. (For example, no point in time is - absolutely speaking - 'twice as late' as another point in time.) Given some arbitrary zero-point, one can express any point in time as an elapsed time measured from that offset. Such an arbitrary zero-point is called an epoch. This epoch-offset form is used as a semantic representation here, without implying that any system would have to implement the TS data type in that way. Systems that do not need to compute distances between points in time will not need any other representation than a calendar expression literal