Thanks for your comments, Colleen. I've changed the subject line to address
your question about BC dates.
EDTF does support BC dates, You can see the following examples at
http://www.loc.gov/standards/datetime/examples.html:
"BC date: -1000-01-01"
"-10000-01-01 ( January 1 of the year 10,000 BC)"
In fact, both of these are supported by xs:date and are thus automatically
supported by EDTF, which is a superset of xs:date.
Note however, EDTF does not support non-hyphenated BC dates. For example,
does not support:
-10000101
even though it supports both:
-1000-01-01
and:
10000101
I.e. DOES support both hyphenated BC dates and non-hyphenated positive
dates. ("Positive" meaning AD/CE.)
So while xs:date does support BC dates, it supports only the hyphenated
form - xs:date does not support the non-hyphenated form of date, BC or
positive. On the other hand, EDTF does support a positive date without
hyphens, even though xs:date does not. This is an EDTF extension to xs:date.
The reason why EDTF does not support the hyphenated form of a BC date - and
this is open for discussion - is that although there is a use case for
non-hyphenated positive dates, no use case has been offered for
non-hyphenated BC dates.
Another limitation, possible of concern to nobody: EDTF does not support
"Year Zero". This has not been raised as an issue and quite likely will not,
unless members of scientific communities which use year zero become
stakeholders in this effort; if that happens we would address this,
otherwise we would not. "Year Zero" means the year between 1BC and 1AD.
For most applications such a year does not exist, 1AD is the year
immediately following 1BC. However for certain disciplines, astronomy for
example, year zero is meaningful. Support of year zero would introduce
serious complexities (for example, alignment of leap years) and we do not
plan to address it any further if nobody raises it as a requirement.
-- Ray
----- Original Message -----
From: "Colleen R Cahill" <[log in to unmask]>
To: <[log in to unmask]>
Sent: Monday, November 23, 2009 7:02 AM
Subject: Re: [DATETIME] Abstract dates and times
Ray,
Very good start. One minor thing; there is a extra "0" in your first
example (should be 20100202).
We have been using that date format in the Geography & Map Division
Scanning Lab for years in a table of administrative metadata because it
sorted the well and was easy to see groupings. While good for machines to
parse, it is also something humans can quickly learn to read. My only
question is how will you deal with BC dates? We have not had to face that
at our shop.
The time field is not something we have used, but it makes sense and if
needed, is the most logical way to display this data. Those who are more
familiar with "military" time will have less of a learning curve, but I
don't foresee anyone being stumped by this. The "T" in front is great as a
hint for what the data is all about, since time is rarely displayed as a
number without some punctuation (i.e. 12:10).
Colleen
Colleen R. Cahill
Digital Conversion Coordinator and
Recommending Officer for Science Fiction and Fantasy
Geography & Map Division
Library of Congress
4652
202-707-8540
>>> "Ray Denenberg, Library of Congress" <[log in to unmask]> 11/19/2009 10:34 AM
>>> >>>
I'll get the discussion started.
See the first proposal on the list at
http://www.loc.gov/standards/datetime/proposals.html. (Just because it's
the first does not mean that these have to be discussed in order. Anyone who
wishes to initiate a thread on any of these proposals, please do. Please use
a meaningful subject line, though.)
Please comment on whether the feature discussed below is useful. Would you
use it? implement it? Please feel free to say no, it is not useful.
Abstract dates and times.
Thus, where:
201000202
is February 2, 2010
something like:
****0202
would simply mean February 2. (As in "Groundhog Day is February 2".)
I am not suggesting this particular syntax, just using it as an example. I
suggest we avoid the syntax discussion and focus on the functionality, and
if it seems that this is a feature worth adopting then talk about syntax.
Also, holidays with no fixed date, Easter for example, are out of scope for
this thread, they are part of a different proposal.
Similarly for time.....
So where:
20090412T133500
means 1335 (1:35 PM), April 12, 2009
Something like:
T133500
would mean 1335 (As in "Sunday day game start times are 1:35 PM".)
(There is a third part to the proposal but let's put that on a separate
thread.)
--Ray
|