Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Document date time formats in mapping process #25

Open
mielvds opened this issue Apr 24, 2013 · 2 comments
Open

Document date time formats in mapping process #25

mielvds opened this issue Apr 24, 2013 · 2 comments
Assignees

Comments

@mielvds
Copy link
Member

mielvds commented Apr 24, 2013

Description

This datatype is modeled after the calendar dates defined in Chapter 5.2.1 of ISO (International Organization for Standardization) 8601. Its value space is the set of Gregorian calendar dates as defined by this standard; i.e., a one-day-long period of time. Its lexical space is the ISO 8601 extended format:

[-]CCYY-MM-DD[Z|(+|-)hh:mm]
with an optional time zone. Time zones that aren't specified are considered undetermined.

Restrictions

The basic format of ISO 8601 calendar dates, CCYYMMDD, isn't supported.

The other forms of dates available in ISO 8601 aren't supported: ordinal dates defined by the year, the number of the day in the year, dates identified by calendar week, and day numbers.

As the value space is defined by reference to ISO 8601, there is no support for any calendar system other than Gregorian. Because the lexical space is also defined using a reference to ISO 8601, there is no support for any localization such as different orders for date parts or named months.

The order relation between dates with and without time zone is partial: they can be compared beyond a +/- 14 hour interval.

There is a difference between ISO 8601, which defines a day as a 24-hour period of time, and the W3C XML Schema, which indicates that a date is a "one-day-long, non-periodic instance ... independent of how many hours this day has." Even though technically correct, some days don't last exactly 24 hours because of leap seconds; this definition doesn't concur with the definition ofxsd:duration that states that a day is always exactly 24 hours long.

Example

Valid values include: 2001-10-26, 2001-10-26+02:00, 2001-10-26Z, 2001-10-26+00:00, -2001-10-26, or -20000-04-01.

The following values would be invalid: 2001-10 (all the parts must be specified), 2001-10-32 (the days part—32—is out of range), 2001-13-26+02:00 (the month part—13—is out of range), or01-10-26 (the century part is missing).

@ghost ghost assigned mielvds Apr 24, 2013
@coreation
Copy link
Member

@mielvds @pietercolpaert is this still relevant?

@mielvds
Copy link
Member Author

mielvds commented Jan 9, 2014

I guess this is Vertere not generating a triple when it is unable to construct a vaid xsd:date, xsd:dateTime, so yes

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants