Instructions for the authority 046 field include this statement:
"The date and time are recorded according to Representations of Dates and Times (ISO 8601) in the pattern yyyy, yyyy-mm, or yyyymmdd (4 for the year, 2 for the month, and 2 for the day) unless subfield $2 (Source of date) specifies another date scheme."
I'm going to assume that the specification of patterns here is mostly to indicate that we want the year before the month, and the month before the day, and is not intended to indicate that these are the only date patterns defined by 8601 (because they're not). Specifically, I'll assume that this statement is not intended to exclude the use of century dates. So for our immediate purposes, I want to focus on the parts of the instruction that mean "Either the contents of the 046 field are constructed according to 8601, or you use subfield $2."
Now, century dates are defined in 8601 as the first two digits of the hundred-year span of interest. (Actually, "century" dates aren't defined in 8601; 8601 identifies two-digit dates that have "less accuracy" than four-digit dates.)
"16" means: 1600-1699
"19" means: 1900-1999
(The standard's avoidance of the term "century" avoids the popular usage, where "17th century", means "the 100-year span ending in 1700"--or 1699, if you persist in that particular error. Neither of these is what's defined in 8601.)
Most of us have made use of the extensions provided for in the Extended Date/Time Format (EDTF) for complex situations, such as approximate dates, or a choice of possible dates. One of the things about EDTF that I (for one) didn't quite grasp until recently, is that century dates are not within the scope of EDTF: century dates (or, more correctly, two-digit dates of lower precision) are in 8601, but not in EDTF. This means, in turn, that (as matters stand) we cannot have 046 fields such as these:
$s 16~
$g [04,05]
$f 17?
These are improperly constructed because they conform neither to 8601 nor EDTF, and yet they do not have subfield $2 indicating the standard which they follow, as required by the MARC definition. I hasten to add that I believe that these are all perfectly reasonable 046 fields to want to have in an authority record; the problem is that they're just not allowed under the current definitions.
There are no doubt several ways out of this small problem. One would be to expand the definition of EDTF to include two-digit dates. Another might be to say that if one needs to apply EDTF techniques to two-digit dates, then the date must be filled out to four characters with "uu". In both of these cases (and no doubt in the case of other resolutions that might be proposed) additional changes to EDTF would be required. But I think that some means must be found to record dates that it appears that we need to be able to record.
What does the collective wisdom think?
Gary L. Strawn, Authorities Librarian, etc. Twitter: GaryLStrawn
Northwestern University Library, 1970 Campus Drive, Evanston IL 60208-2300
e-mail: [log in to unmask] voice: 847/491-2788 fax: 847/491-8306
Forsan et haec olim meminisse iuvabit.
|