Print

Print


(Sent to MODS and PREMIS; cc'd to dateTime for information only.)

PREMIS and MODS implementers, the work on the dateTime draft spec, http://www.loc.gov/standards/datetime/spec.html, was originally motivated by the lack of support for PREMIS requirements in standard date/time formats such as W3CDTF. It has grown beyond that, but one of the driving requirments was to represent dates and times without hyphens and colons, for example:
   '02142011T0915'   ("basic form" in ISO 8601 terminology)
instead of 
   '02-14-2011T09:15' ("extended form")

MARC uses the basic form, so the draft spec currently includes this form. The extended form is also included, by popular demand. So both forms are included, and there is strong objection to including both; the sentiment is that one or the other should be dropped, and since the extended form cannot be dropped (for a number of reasons), the basic form should be dropped. 

My question is, is there popular support for the basic form, perhaps among developers who are not (yet) participating in this discussion?   If you have a position on this matter then you should subscribe to the dateTime listserv (http://www.loc.gov/standards/datetime/listserv.html) and make your position known.  

The most recent discussion on this matter is:
http://listserv.loc.gov/cgi-bin/wa?A2=ind1102&L=datetime&T=0&P=1916 
http://listserv.loc.gov/cgi-bin/wa?A2=ind1102&L=datetime&T=0&P=2209  

If no support for the basic feature is expressed on the dateTime listserv, the feature will be dropped.  

Ray Denenberg


----------------------------------------------------------------------------
------------------

-----Original Message-----
From: Discussion of the Developing Date/Time Standards [mailto:[log in to unmask]] On Behalf Of Syd Bauman
Sent: Sunday, February 13, 2011 9:52 PM
To: [log in to unmask]
Subject: Re: [DATETIME] hyphens and colons

Maybe I'm being dense, but I don't see how this is a legitimate use case.
Dates as represented in MARC will not, in the general case, conform to our specification no matter what we do.[1] If the MARC date happens to conform to our current 201 or 202, then it is trivial to convert them from the basic form to the extended form. In Perlese it would be
    $date     =~ s,(\d{4})(\d{2})(\d{2}),$1-$2-$3,;
    $dateTime =~
s,(\d{4})(\d{2})(\d{2})T(\d\d)(\d\d)(\d\d),$1-$2-$3T$4:$5:$6,;
(without any error checking :-)

For the moment, at least, I'm completely against the basic form.

Note
----
[1] I don't have AACR2 in front of me right now, but I do have the
    XSLT I've started to write to handle generic AACR2 dates. Here
    are the formats it has to handle:
      1.4F1 1: 1975
      1.4F1 2: 4308 [1975]
      1.4F1 3: [4308 i.e. 1975]
      1.4F1 4: 5730 [1969 or 1970]
      1.4F1 5: anno 18 [1939]
      1.4F2: 1697 [i.e. 1967]
      1.4F6 1: c1967
      1.4F6 3: p1983
      1.4F6 2, 4: 1967 printing, 1979 pressing
      1.4F7 1: [1971 or 1972]
      1.4F7 2: [1969?]
      1.4F7 3: [between 1906 and 1912]
      1.4F7 4: [ca. 1960]
      1.4F7 5: [197-]
      1.4F7 6: [197-?]
      1.4F7 7: [18--]
      1.4F7 8: [18--?]


> The issue of hyphens in dates and colons in times was raised by 
> several members here, suggesting that only one form, basic (no hyphens 
> or colons) or extended (hyphens and colons included), be prescribed in 
> the dateTime spec. And since we cannot profile out the extended form 
> (for a number of reasons) that would mean profiling out the basic 
> form.
> 
> The argument for the basic form is that MARC records use the basic 
> form for both date and dateTime, so if basic form is profiled out then 
> marc records would not conform to the spec, unless they are converted, 
> which is unlikely.
> 
> I have consulted with a MARC expert and we conclude that only items
> 201 and 202 matter - "201: Date - without hyphen" and "202:
> Date/time - without hyphen/colon". There is no existing data in MARC 
> records for any other item in the spec (we think). So there is no 
> reason to allow both forms, for (for example) "2004-06-(11)?"
> because there is no data of this form yet.
> 
> So we propose that 201 and 202 are legitimate use cases and that both 
> basic and extended forms be allowed, but only for date
> (yyyymmdd) and dateTime, and in all other cases only the extended form 
> be permitted.