Date Time Data Types
Recommendation, 2004-08-02
This version:
DateTimeDataTypes.doc
Previous version:
DateTimeDataTypes.doc
Editor:
Don Simonson, Robert Haft International
Eric Johns, ESOXML
Karl Brophey, EbenX
Kim Bartkus, HR-XML
Scott Miller, IBM
Paul Kiel, HR-XML
Tim Farlow, Authoria
Authors:
Mark Marsden, Ultimate Software
Contributors:
Members of Cross Process Objects workgroup
Copyright statement
©2004 HR-XML. All rights reserved. No part of this publication may be reproduced, stored in a retrieval system, or transmitted, in any form or by any means, electronic, mechanical, photocopying, recording, or otherwise, without the prior written permission of the publisher. Printed in the United States of America.
Abstract
The date, time and dateTime data types provided in the Schema Recommendation allows for an optional time zone designation. In Consortium work, there will be times when the precise date, time or dateTime value must be known. The objective of this document is to provide HR-XML Schema designers the ability to require or prohibit the Time Zone designation for date, time and dateTime values in a consistent manner.
Status of this Document
2004-Aug-2: This specification remains unchanged from the 2003-November release. The version number (2004-08-02) has been updated on the document title page and the “version” attribute of the “xsd:schema” element.
The “AnyDateTimeTypes” used AnyDateTimeType as a memberType in its union. AnyDateTimeType is itself a union of types. This created a syntax of a “union of unions”. In order to be as clear as possible, and to avoid differing parser interpretation of this syntax, the AnyDateTimeType memberTypes are included explicitly.
<!--
This is the original text from the previous release:
-->
<xsd:simpleType name="AnyDateTimeType">
<xsd:union memberTypes="LocalDateType DateType LocalDateTimeType DateTimeType"/>
</xsd:simpleType>
<xsd:simpleType name="AnyDateTimeNkType">
<xsd:union memberTypes="AnyDateTimeType NotKnownLiteral"/>
</xsd:simpleType>
<xsd:simpleType name="AnyDateTimeNaType">
<xsd:union memberTypes="AnyDateTimeType NotApplicableLiteral"/>
</xsd:simpleType>
<xsd:simpleType name="AnyDateTimeNkNaType">
<xsd:union memberTypes="AnyDateTimeType NotKnownLiteral NotApplicableLiteral"/>
</xsd:simpleType>
<!--
This is the new syntax which eliminates the "union of unions":
-->
<xsd:simpleType name="AnyDateTimeType">
<xsd:union memberTypes="LocalDateType DateType LocalDateTimeType DateTimeType"/>
</xsd:simpleType>
<xsd:simpleType name="AnyDateTimeNkType">
<xsd:union memberTypes="LocalDateType DateType LocalDateTimeType DateTimeType NotKnownLiteral"/>
</xsd:simpleType>
<xsd:simpleType name="AnyDateTimeNaType">
<xsd:union memberTypes="LocalDateType DateType LocalDateTimeType DateTimeType NotApplicableLiteral"/>
</xsd:simpleType>
<xsd:simpleType name="AnyDateTimeNkNaType">
<xsd:union memberTypes="LocalDateType DateType LocalDateTimeType DateTimeType NotKnownLiteral NotApplicableLiteral"/>
</xsd:simpleType>
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119.
Table of Contents
1.3.2 Items Within the Design Scope
1.3.3 Items Outside of Design Scope
2 Supported Business Processes
2.2 Business Process Decision Drivers
3.1.2 Schema Elements Explained
4 Implementation Considerations
6 Appendix B – Character Representations and Designators
7 Appendix C - Document Version History
8 Appendix D - Related Documents
9 Appendix E – Reference Examples
1 Overview
1.1 Objective
The objective of this document is to provide HR-XML Schema designers the tools to incorporate date, time and dateTime values into their work processes in a consistent manner. This is achieved through the use of standard data types, which permit an XML parser to ensure the validity of a desired style of data. Each work group can define its own business process needs and apply any of the applicable "dateTime" data types defined herein which match that need.
1.1.1 Domain Issues
In the HR space, there are many instances where a point in time needs to be captured. The preciseness of the date/time value is often dependent on the business context. A hire date can often be captured as date value, the exact time a person is hired is not important in many transactions. An incident date requires more precision. Many transactions require the date and time an incident took place. Also, in the case of an incident, the time zone may be required. Eleven o’clock in the evening on July 31 in Washington DC, is four o’clock in the morning on August 1 in London. This could mean a difference in coverage for the employee.
Another issue with the current Schema Recommendation is the fact that the time zone designation is optional. A business partner can receive multiple instance documents based on the same schema design. Some documents can contain a dateTime data element that has the time zone, and some of the documents can contain the same dateTime data element that does not contain the time zone. The business partner has no way of ordering the documents based on this dateTime date element.
1.1.2 Business Reasons
Almost all HR and Payroll business processes revolve around some event or string of events in time. All these events have in common a start point, an end point, a duration, or some combination of these, that must be represented in a format that can be efficiently stored, conveyed and processed by HRIS systems. By developing a standard approach to providing date information we will prevent the necessity of other HR-XML Consortium work groups from devoting time and effort to addressing this on a case-by-case basis.
1.2 Design Requirements
The date, time and dateTime data types provided in the Schema Recommendation of May 2, 2001 allows for an optional time zone designation. In Consortium work, there will be times when the precise date, time or dateTime value must be known. The objective of this document is to provide HR-XML Schema designers the ability to require or prohibit the TimeZone designation for date, time and dateTime values in a consistent manner.
The Design requirements must take into account the following:
1. A global concept of time
2. Representing Date and Time values in Schema
3. Allow a Date and/or Time value to be stored as a data element or as a data attribute
1.3 Scope
1.3.1 Major Components
Deliver standard Date, Time and DateTime data types that will be used by all of the work groups within the consortium. The goal is consistency.
Provide a yardstick that the CPO can use as a basis for reviewing other workgroup’s schema designs.
1.3.2 Items Within the Design Scope
Representing a point in time
Representing a time period (An interval of time with a start and an end)
Representing an unknown date, time or date/time value
Representing an open ended date/time value
Provide standard data types for:
1. Local Date, Local Time, Local DateTime
2. Global Date, Global Time, Global DateTime
1.3.3 Items Outside of Design Scope
Time scheduling rules, such as ‘7 days before Christmas’ are not addressed in this document. Likewise scheduling items of the form ‘Every Tuesday at 10:00AM’ or ‘Every Monday through Friday from 3:30PM to 4:00PM’ is not addressed in this document. It is encouraged that for these needs the relevant schema data types be used when possible.
Representing a “duration of time” (2 days, 4 hours, 13 minutes) will not be addressed in this version of the document.
Representing a partial date, such as 2001-06 or a partial time, such as 12:00.
2 Supported Business Processes
2.1 Trading Partner Roles
The purpose of this recommendation is to provide a standard representation for date and time values to schema designers within the consortium, trading partner roles do not apply to this document.
2.2 Business Process Decision Drivers
Before reading this section, you should have a good understanding of the vocabulary defined in Appendix A.
Once it has been determined that a time value needs to be captured, the schema designer should consider how the following issues affect the time value being captured:
Local Time vs. Global Time – If the time value being communicated is representative of a specific point in time in a specific location, then a global time value should be captured. If the time being communicated is representative of a relative point in time, independent of time zone, then a local time value should be used. When in doubt, use a global time value.
Consider the following examples:
Global Time Value:
Business A is located in Washington DC (5 hours behind UTC).
Business B is located in London (0 hours behind UTC).
Business A sends a time value of 2001-04-01T09:30:00 for an employee living in California
(8 hours behind UTC).
Problem: How can business B determine the correct time the event really happened? Is it 9:30 Washington time, 9:30 California time or 9:30 London time?
Solution: Business A sends a time value of 2001-04-01T09:30:00-05:00. Now its clear that the time the event occurred was 9:30 Washington time. Business B can use this information to calculate the time the event occurred in California time or London time as well.
Local Time Value:
An employee lives and works in California (8 hours behind UTC).
The employee's benefit plan, including medical coverage, becomes effective at
midnight 2000-08-01 local time. This applies to claims incurred on or after
that point in time, where they seek care.
Problem: The employee has an accident requiring medical attention at 2000-08-01T02:00:00 London Time. (2000-07-31T17:00:00 California Time). Is the medical coverage in effect?
Solution: The coverage is in effect on 2000-08-01. The accident occurred at 2000-08-01T02:00:00+00:00. Since one date has a time zone and the other does not, the system should consider the coverage in effect (Year, Month and Day are equal). By explicitly not sending the time zone, it is being communicated that the start of coverage is 2000-08-01. Had the accident occurred at the same point in time, but in California instead of London, the coverage would not be in effect.
Precision – Is the date precise enough, or is a
specific point in time (date & time) required?
A hire date is an example where the date value is usually precise enough. Most
employers are not concerned with the exact second an employee was hired. An
incident date, on the other hand may require a precise date and time value. The
time of day may be all that’s required for a child data element when the parent
data element contains the date.
Unbounded / Not Applicable Date Values – Is it acceptable to have a date value that conveys a ‘maximum date’ value, a ‘minimum date’ value or ‘date value does not apply’? This is common in date ranges. An employee’s start date is 2001-04-01. The currently employed employee’s termination date has yet to be determined. For processing purposes we want to convey the termination date is notApplicable.
Unknown Date Values – Is it possible for the sending system to not know the date value being captured? Is this acceptable? If so, we want to be able to communicate this state to the receiving system. This is done using the notKnown value. An employee’s start date is 2001-04-01. The sending system does not know the current status of the employee. It would send the notKnown value in the employee’s termination date.
3 Schema Design
The best way to explain the CPO Date Data types is to describe how a designer might want their data element/attribute to behave. The issue with the Schema Date, Time and DateTime data types is that they are a little too lenient when it comes to the time zone designator. Most likely, the schema designer will want to enforce or prohibit the time zone designator of the date/time value. This would provide a consistent format for date/time values received in any given element/attribute. The date/time data type names can be broken down as follows:
short description - The value the element/attribute represents (i.e. Date, Time, DateTime) Any description with the word ‘Local’ before the short description, defines a value that does not contain a time zone designator. Descriptions without the word ‘Local’ define a value that must contain a time zone designator, and will contain a global time value or a value that can be easily converted to a global time value.
Nk – The data element/attribute can contain a valid date/time value or the word notKnown
Na – The data element/attribute can contain a valid date/time value or the word notApplicable
Type – Indicates that this name is not meant to be a data element/attribute name, but is meant to be the foundation for the data elements and attributes.
For example an element/attribute of type LocalDateNkNaType will contain a valid date value in the format of YYYY-MM-DD, or the value notKnown, or the value notApplicable. The element/attribute cannot contain any other value. (If it does, the full document will be considered not valid.)
|
Data Type |
Basic Format |
Time |
not
Known |
not |
|
DateType |
YYYY-MM-DD(Z | ±hh:mm) |
Yes |
|
|
|
DateNkType |
YYYY-MM-DD(Z | ±hh:mm) |
Yes |
Yes |
|
|
DateNaType |
YYYY-MM-DD(Z | ±hh:mm) |
Yes |
|
Yes |
|
DateNkNaType |
YYYY-MM-DD(Z | ±hh:mm) |
Yes |
Yes |
Yes |
|
LocalDateType |
YYYY-MM-DD |
|
|
|
|
LocalDateNkType |
YYYY-MM-DD |
|
Yes |
|
|
LocalDateNaType |
YYYY-MM-DD |
|
|
Yes |
|
LocalDateNkNaType |
YYYY-MM-DD |
|
Yes |
Yes |
|
TimeType |
hh:mm:ss(Z | ±hh:mm) |
Yes |
|
|
|
TimeNkType |
hh:mm:ss(Z | ±hh:mm) |
Yes |
Yes |
|
|
TimeNaType |
hh:mm:ss(Z | ±hh:mm) |
Yes |
|
Yes |
|
TimeNkNaType |
hh:mm:ss(Z | ±hh:mm) |
Yes |
Yes |
Yes |
|
LocalTimeType |
hh:mm:ss |
|
|
|
|
LocalTimeNkType |
hh:mm:ss |
|
Yes |
|
|
LocalTimeNaType |
hh:mm:ss |
|
|
Yes |
|
LocalTimeNkNaType |
hh:mm:ss |
|
Yes |
Yes |
|
DateTimeType |
YYYY-MM-DDThh:mm:ss(Z | ±hh:mm) |
Yes |
|
|
|
DateTimeNkType |
YYYY-MM-DDThh:mm:ss(Z | ±hh:mm) |
Yes |
Yes |
|
|
DateTimeNaType |
YYYY-MM-DDThh:mm:ss(Z | ±hh:mm) |
Yes |
|
Yes |
|
DateTimeNkNaType |
YYYY-MM-DDThh:mm:ss(Z | ±hh:mm) |
Yes |
Yes |
Yes |
|
LocalDateTimeType |
YYYY-MM-DDThh:mm:ss |
|
|
|
|
LocalDateTimeNkType |
YYYY-MM-DDThh:mm:ss |
|
Yes |
|
|
LocalDateTimeNaType |
YYYY-MM-DDThh:mm:ss |
|
|
Yes |
|
LocalDateTimeNkNaType |
YYYY-MM-DDThh:mm:ss |
|
Yes |
Yes |
|
AnyDateTimeType |
YYYY-MM-DD |
Optional |
|
|
|
AnyDateTimeNkType |
YYYY-MM-DD |
Optional |
Yes |
|
|
AnyDateTimeNaType |
YYYY-MM-DD |
Optional |
|
Yes |
|
AnyDateTimeNkNaType |
YYYY-MM-DD |
Optional |
Yes |
Yes |
|
· (Z | ±hh:mm) means that either the letter Z or a time zone designator in the form of +hh:mm or -hh:mm is allowed. ·
In all of the Basic Formats with
a time zone designator (±hh:mm), · When the letter Z is used in a DateTime expression the value is said to be a Coordinated Universal Time value. ·
When the time zone designator (±hh:mm) is used in a DateTime
expression, the value is a local time value. · All of the following are true: · 2001-04-01T06:00:00-05:00 = 2001-04-01T11:00:00Z · 2001-04-01T06:00:00+07:00 = 2001-03-31T23:00:00Z · 2001-04-01T06:00:00+00:00 = 2001-04-01T06:00:00Z ·
The only valid formats for
Coordinated Universal Time are the following: |
||||
3.1 Schema Details
3.1.1 Schema Diagrams
The purpose of this document is to define data types for use with data elements/attributes that contain a date or a date/time value. A Schema diagram does not apply for this document. Please review the Reference Examples in appendix B for sample diagrams/schemas using the data types defined in this document. Appendix C contains the Schema source for these data types.
3.1.2 Schema Elements Explained
|
Component Name
|
ContentModel |
Definition |
|
Global simpleTypes: |
|
|
|
/ |
xsd:restriction base: xsd:string [Enumerations]: notKnown |
Allows only the value ‘notKnown’ to be a valid value for elements/attributes of this type |
|
/ |
xsd:restriction base: xsd:string [Enumerations]: notApplicable |
Allows only the value notApplicable to be a valid value for elements/attributes of this type |
|
/ |
xsd:restriction base: xsd:date |
Allows
only a valid date value to be entered in the format
The parser will verify that the value is a valid date. |
|
/ |
- [Union]: LocalDateType, NotKnownLiteral |
Allows
the value ‘notKnown’ or a valid date value in the format:
The parser will verify that the value is a valid date. |
|
/ |
- [Union]: LocalDateType, NotApplicableLiteral |
Allows the value ‘notApplicable’ or a valid date value in the format: LocalDateType
The parser will verify that the value is a valid date. |
|
/ |
- [Union]: LocalDateType, NotKnownLiteral, NotApplicableLiteral |
Allows
the value ‘notKnown’, ‘notApplicable’, or a valid date value in the
format:
The parser will verify that the value is a valid date. |
|
/ |
xsd:restriction base: xsd:date |
Allows
only a valid date value to be entered in the formats:
The parser will verify that it is a valid date and time zone. |
|
/ |
- [Union]: DateType, NotKnownLiteral |
Allows
the value ‘notKnown’ or a valid date value in the format:
The parser will verify that it is a valid date and time zone. |
|
/ |
- [Union]: DateType, NotApplicableLiteral |
Allows
the value ‘notApplicable’ or a valid date value in the format:
The parser will verify that it is a valid date and time zone. |
|
/ |
- [Union]: DateType, NotKnownLiteral, NotApplicableLiteral |
Allows
the value ‘notKnown’, ‘notApplicable’, or a valid date value in the
format:
The parser will verify that it is a valid date and time zone. |
|
/ |
xsd:restriction base: xsd:time |
Allows
only a valid time value to be entered in the following format: |
|
/ |
- [Union]: LocalTimeType, NotKnownLiteral |
Allows
the value ‘notKnown’ or a valid time value in the format:
The parser will verify that the value is a valid time. |
|
/ |
- [Union]: LocalTimeType, NotApplicableLiteral |
Allows
the value ‘notApplicable’ or a valid time value in the format:
The parser will verify that the value is a valid time. |
|
/ |
- [Union]: LocalTimeType, NotKnownLiteral, NotApplicableLiteral |
Allows
the value ‘notKnown’, ‘notApplicable’, or a valid time value in the
format:
The parser will verify that the value is a valid time. |
|
/ |
xsd:restriction base: xsd:time |
Allows only
a valid time value to be entered in one of the following formats: |
|
/ |
- [Union]: TimeType, NotKnownLiteral |
Allows
the value ‘notKnown’ or a valid time value in the format:
The parser will verify that the value is a valid time. |
|
/ |
- [Union]: TimeType, NotApplicableLiteral |
Allows
the value ‘notApplicable’ or a valid time value in the format:
The parser will verify that the value is a valid time. |
|
/ |
- [Union]: TimeType, NotKnownLiteral, NotApplicableLiteral |
Allows
the value ‘notKnown’, ‘notApplicable’, or a valid time value in the
format:
The parser will verify that the value is a valid time. |
|
/ |
xsd:restriction base: xsd:dateTime |
Allows
only a valid date/time value to be entered in the following format: |
|
/ |
- [Union]: LocalDateTimeType, NotKnownLiteral |
Allows
the value ‘notKnown’ or a valid date/time value in the format:
The parser will verify that the value is a valid date and time. |
|
/ |
- [Union]: LocalDateTimeType, NotApplicableLiteral |
Allows
the value ‘notApplicable’ or a valid date/time value in the format:
The parser will verify that the value is a valid date and time. |
|
/ |
- [Union]: LocalDateTimeType, NotKnownLiteral, NotApplicableLiteral |
Allows
the value ‘notKnown’, ‘notApplicable’, or a valid date/time value in
the format:
The parser will verify that the value is a valid date and time. |
|
/ |
xsd:restriction base: xsd:dateTime |
Allows
only a valid date/time value to be entered in one of the following formats: |
|
/ |
- [Union]: DateTimeType, NotKnownLiteral |
Allows
the value ‘notKnown’ or a valid date/time value in the format:
The parser will verify that the value is a valid date and time. |
|
/ |
- [Union]: DateTimeType, NotApplicableLiteral |
Allows
the value ‘notApplicable’ or a valid date/time value in the format:
The parser will verify that the value is a valid date and time. |
|
/ |
- [Union]: DateTimeType, NotKnownLiteral, NotApplicableLiteral |
Allows
the value ‘notKnown’, ‘notApplicable’, or a valid date/time value in
the format:
The parser will verify that the value is a valid date and time. |
|
/ |
- [Union]: LocalDateType,DateType,LocalDateTimeType,DateTimeType |
Allows valid date or a date/time value to be entered in one of the following formats: YYYY-MM-DD YYYY-MM-DDZ YYYY-MM-DD+hh:mm YYYY-MM-DD-hh:mm
YYYY-MM-DDThh:mm:ss |
|
/ |
- [Union]: LocalDateType,DateType,LocalDateTimeType,DateTimeType, NotKnownLiteral |
Allows
the value ‘notKnown’ or a valid date/time value in the format:
The parser will verify that the value is a valid date (and time). |
|
/ |
- [Union]: LocalDateType,DateType,LocalDateTimeType,DateTimeType, NotApplicableLiteral |
Allows
the value ‘notApplicable’ or a valid date/time value in the format:
The parser will verify that the value is a valid date (and time). |
|
/ |
- [Union]: LocalDateType,DateType,LocalDateTimeType,DateTimeType, NotKnownLiteral, NotApplicableLiteral |
Allows
the value ‘notKnown’, ‘notApplicable’, or a valid date/time value in
the format:
The parser will verify that the value is a valid date (and time). |
4 Implementation Considerations
1.
All elements and attributes designed to contain a date, a time or a dateTime
value should be defined as one of the date, time or dateTime data types
described above.
By asking the following questions, you can quickly determine which data type to
use:
|
Question |
Determination |
|
Are we capturing a specific point in time in a specific location, such as Hire Date? - OR - Are we capturing a relative point in time independent of time zones, such as Benefit Start Date? |
We want to capture a time that is global in nature. Do not use data types with the word ‘Local’ in the name
|
|
Do we need to capture a date value or do we need to be more specific and capture a date/time value? |
If the date value is important and the time value is not needed, look for a type with DateType in the Content Model.
|
|
Are we allowing a ‘maximum’ or ‘minimum’ date value to be allowed? |
If the answer is yes, look for a type with notApplicableLiteral in the Content Model |
|
Are we allowing the sending system to admit it doesn’t know the value of the date? |
If the answer is yes, look for a type with notKnownLiteral in the Content Mode. |
|
Examples |
|
|
Example 1: For a Hire Date, we don’t care about a time value. Also, the sending system may not know the value. |
element name = "HireDate" |
|
Example 2: For a date range, The sending system may not know the start date. The end date will either be a valid date, or it could be open ended. |
element name = "StartDate" element Name = “EndDate” |
|
Example 3: The Transaction Date must be very precise. It cannot be unknown or unbounded. |
element name=”TransactionDate” |
2. Required & Optional properties, and Default Values – There are a number of facets of a Date/Time element/attribute that can affect how the parser determines the value of the element/attribute. Consider the following:
|
Schema Definition |
Instance Document Value |
Parsed Value |
|
StartDate defined as a data element: Optional (1st) then Required (2nd) |
||
|
<xsd:element |
<StartDate>notApplicable |
notApplicable |
|
<StartDate>notKnown |
notKnown |
|
|
<StartDate></StartDate> |
Parser Error |
|
|
Data Element does not exist |
??? |
|
|
<xsd:element |
<StartDate>notApplicable </StartDate> |
notApplicable |
|
<StartDate></StartDate> |
Parser Error |
|
|
Data Element does not exist |
Parser Error |
|
|
StartDate defined as an optional attribute (with and without a default value) |
||
|
<xsd:attribute |
startDate=”notApplicable” |
notApplicable |
|
startDate=”notKnown” |
notKnown |
|
|
Attribute does not exist |
notKnown |
|
|
<xsd:attribute |
startDate=”notApplicable” |
notApplicable |
|
Attribute does not exist |
??? |
|
|
StartDate defined as a required attribute |
||
|
<xsd:attribute |
startDate=”notKnown” |
notKnown |
|
Attribute does not exist |
Parser Error |
|
The advantages of defining an optional attribute, with a default value, is (1) the instance document can be smaller, notKnown (or notApplicable) values can be omitted from the instance document; (2) The meaning of the omitted attribute is clear.
- In any time period represented using a start and end data elements/attributes, the start and end values are inclusive in the time period.
- This Schema design depends on the CPO DateTime Data Types Schema being available for inclusion into other schemas. While the Technical Steering Committee sets up and defines the infrastructure to make this possible, the Schema Types in Appendix F should be copied into the Schema being developed
5 Appendix A - Vocabulary
Complete Representation – The representation that includes all the date and time elements associated with the expression. The Schema standard requires the complete representation of date, time and dateTime expressions.
Greenwich Mean Time
(GMT) – The official time reference
for the world until 1972. Greenwich Mean Time is the mean solar time for the meridian at Greenwich, England.
This time scale is based on the earth’s motion, which fluctuates in rate by a
few thousandths of a second a day. The Royal Greenwich Observatory is the
authority of GMT.
Also known as Zulu Time, Z Time and World Time.
Coordinated Universal Time (UTC) – The
official time reference for the world since
1972-01-01. UTC runs at the rate of the atomic clock. UTC is almost the same
as GMT. As the variation between the two time scales approaches a second, a 1
second adjustment (a leap second) is made in UTC. The international UTC time
scale is coordinated in Paris by the International Bureau of Weights and
Measures (BIPM)
Midnight – The complete representation of midnight
can have one of two forms. 00:00:00 represents the beginning of the day.
24:00:00 represents the end of the day.
24:00:00 on 1985 April 12 is the same as 00:00:00 on 1985 April 13
(ISO 8601:2000(E) section 5.3.2 Midnight)
date, calendar – Identification of a particular calendar day, by its calendar year, its calendar month and its ordinal number within its calendar month (ISO:8601:2000(E);Section 3.3 – date, calendar)
dateTime data type– The identification of a particular point in time by its calendar date element and its time of day element, represented as a single expression.
local time – Clock time in public use locally.
NOTE – The difference between local time and UTC time is established by the
(national, regional or local) authority responsible for these matters. The
difference depends upon the time zone and may also be varied in the course of a
year. (ISO 8601:2000(E) section 3.13 local time)
global time – The representation of local time in one location in such a manner that it can be converted to the local time in another location, anywhere in the world.
period of time – The portion of time between two time
points. Also known as a time-interval.
(ISO 8601:2000(E) section 3.17 period of time)
Note: Periods of time should be represented using a pair of similarly defined
data elements or attributes. The start and end values should be inclusive.
duration of time – a quantity (“length”) of time (i.e. 4 days, 2 hours, 26 minutes, 10 seconds).
6 Appendix B – Character Representations and Designators
Character Representations and Designators used in date, time and dateTime expressions (paraphrased from ISO 8601:200(E) sections 5.1.1 and 5.1.2):
YYYY – represents a four digit year time element
MM – represents a two digit month time element
DD – represents a two digit day time element
hh – represents a two digit hour time element
mm – represents a two digit minute time element
ss – represents a two digit second time element
n – represents digit(s), constituting a positive integer or zero
T – time designator, indicates the start of the representation of the time of day in combined date and time of day expressions
Z – UTC designator, immediately (without space) following a data element expressing the time of the day in Coordinated Universal Time (UTC)
Literals used in date, time and dateTime expressions:
notApplicable – When a period of time is “Unbounded”, the “notApplicable” value is used to represent this state. For a period of time, a “notApplicable” value in the “Start Date” represents the beginning of time. A “notApplicable” value in the “End Date” represents the end of time. When “notApplicable” is used to represent a point in time, its meaning must be made clear. For example, “notApplicable” in a “Deceased Date” could mean the employee is still among the living.
notKnown – When a point in time is unknown, the “notKnown” value is used to represent this state. The “notKnown” literal value and the NULL value represent the same state for a date field. By using the “notKnown” literal value, we make it possible to convey this state when a date value is represented as an attribute. Using the example above, a “notKnown” value in a “Deceased Date” would mean the sending system is not able to provide this information.
7 Appendix C - Document Version History
|
Version |
Date |
Description |
|
1.1 |
2001-08-23 |
Converted to final schema recommendation namespace. |
|
1.1 |
2001-Oct-16 |
Approved recommendation by HR-XML Consortium |
|
1.1 |
2003-Jan-01 |
Namspace changes and Any** membertypes put in explicitly. Not content model changes. DTD sections removed. Schema appendix removed. Fonts adjusted on xml for readability. |
|
1.1 |
2003-02-26 |
Approved recommendation by HR-XML Consortium. The default and targetNamespaces of all HR-XML schemas have been standardized to "http://ns.hr-xml.org". This recommendation is available as part of the HR-XML 2_0 architecture. |
8 Appendix D - Related Documents
ISO 8601 2nd Edition; ISO8601:2000(E); pub 2000-12-15 – Data elements and interchange formats – Information interchange – Representation of dates and times– http://www.iso.ch/cate/d26780.html/
XML Schema Part 0: Primer– http://www.w3.org/TR/xmlSchema-0/
XML Schema Part 2: Datatypes – http://www.w3.org/TR/xmlSchema-2/
Coordinated Universal Time Defined - http://www.its.bldrdoc.gov/fs-1037/dir-009/_1277.htm
A Walk through Time; World Time Scales – http://physics.nist.gov/GenInt/Time/world.html
9 Appendix E – Reference Examples
Sample Schema
<xsd:schema targetNamespace="http://ns.hr-xml.org/2004-08-02" xmlns="http://ns.hr-xml.org/2004-08-02" xmlns:xsd="http://www.w3.org/2001/XMLSchema" elementFormDefault="qualified" version="2_0">
<xsd:include schemaLocation="../CPO/DateTimeDataTypes.xsd"/>
<xsd:element name="RootElement">
<xsd:complexType>
<xsd:sequence>
<xsd:element name="LocalDate" type="LocalDateNkNaType" maxOccurs="unbounded"/>
<xsd:element name="Date" type="DateNkNaType" maxOccurs="unbounded"/>
<xsd:element name="LocalTime" type="LocalTimeNkNaType" maxOccurs="unbounded"/>
<xsd:element name="Time" type="TimeNkNaType" maxOccurs="unbounded"/>
<xsd:element name="LocalDateTime" type="LocalDateTimeNkNaType" maxOccurs="unbounded"/>
<xsd:element name="DateTime" type="DateTimeNkNaType" maxOccurs="unbounded"/>
<xsd:element name="AnyDateTime" type="AnyDateTimeNkNaType" maxOccurs="unbounded"/>
</xsd:sequence>
</xsd:complexType>
</xsd:element>
</xsd:schema>
Sample Valid XML Document
<RootElement xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns="http://ns.hr-xml.org/2004-08-02" xsi:schemaLocation="http://ns.hr-xml.org/2004-08-02
DateTimeDataTypesSample.xsd">
<LocalDate>notKnown</LocalDate>
<LocalDate>notApplicable</LocalDate>
<LocalDate>2001-12-31</LocalDate>
<Date>notKnown</Date>
<Date>notApplicable</Date>
<Date>2001-12-31+05:00</Date>
<LocalTime>notKnown</LocalTime>
<LocalTime>notApplicable</LocalTime>
<LocalTime>12:13:14</LocalTime>
<Time>notKnown</Time>
<Time>notApplicable</Time>
<Time>12:13:14Z</Time>
<Time>12:13:14-05:00</Time>
<LocalDateTime>notKnown</LocalDateTime>
<LocalDateTime>notApplicable</LocalDateTime>
<LocalDateTime>2001-12-31T12:13:14</LocalDateTime>
<DateTime>notKnown</DateTime>
<DateTime>2001-12-31T12:13:14Z</DateTime>
<DateTime>2001-12-31T12:13:14-05:00</DateTime>
<AnyDateTime>notKnown</AnyDateTime>
<AnyDateTime>notApplicable</AnyDateTime>
<AnyDateTime>2001-12-31</AnyDateTime>
<AnyDateTime>2001-12-31T12:13:14</AnyDateTime>
<AnyDateTime>2001-12-31T12:13:14Z</AnyDateTime>
<AnyDateTime>2001-12-31T12:13:14+05:00</AnyDateTime>
</RootElement>