Anyone who has tried to parse dates already knows what this piece is going to be about. This is because dates, which seem so easy on the face of it, are very complex entities that create any number of difficulties for software. I mean, witness the whole Y2K debacle. And that’s just for starters.
There is tremendous variation in how dates are recorded — not just within MARC, by in just about any metadata standard. A while back when I was harvested metadata from library repositories using the OAI-PMH protocol, I found all of the following date notation variations, and these are just for starters:
- 1991-10-01
- ca. 1920.
- (ca). 1920)
- 2001.06.08 by CAD
- Unknown
- ca. June 19, 1901.
- (ca). June 19, 1901)
- [2001 or 2002.]
- 1853.
- c1875.
- c1908 November 19
- 1929 June 6
- [between 1904 and 1908]
- [ca. 1967]
- 1918 ?
- [1919 ?]
- 191-?
- 1870 December, c1871
- 1920, 1921, 1922, 1923, 1924, 1925, 1926, 1927, 1928, 1929
It’s plain to see that the last item was a work-around for a date range of 1920-1929, or the 1920s. Most library search systems find date ranges difficult, so the solution at least one library used was to expand a range into individual years. Meanwhile, these and other work-arounds get exposed out to metadata aggregators in all of their…uh…glory.
So that’s why when a number of years ago my former colleague at the California Digital Library, John Kunze, proposed the TEMPER syntax, I sat up and took notice. Here was an easy, straightforward, easy-to-parse-with-software and human-readable way to store dates. Oddly enough, the proposal doesn’t seem to have had much traction yet. But if I needed a date standard to follow, I’d follow this one. And yes, I’m aware of ISO 8601 and the W3C Date and Time Formats, both of which have their issues.
I mean, the name alone is worth the price of admission. Now TEMPER, TEMPER.
I wonder if the Library of Congress folks working on the Extended Date/Time Format are aware of TEMPER: http://www.loc.gov/standards/datetime/pre-submission.html
Ryan, Thanks for pointing that out! I hadn’t known of the work. Although I notice that TEMPER was mentioned at one point in the related discussion, there doesn’t appear to be any evidence that John Kunze’s work was considered — rather, it seems to seek to be a “profile” of 8601 and therefore tracks that standard’s suggested practices more than TEMPER.