The SolrMarc example/default configuration tries to get a publication date out of 260$c.
This is a tricky thing to do, because you’re trying to parse not entirely coded data. And on top of that, I just discovered that dates in other calendar systems can legally appear in 260$c, if that’s how they appear on the title page. A title page has Hebrew Callendar 5750 in it? That’ll be in the 260$c. Oops.
So it’s probably better to try and get dates out of the 008 fixed field. One problem here is it’s a lot more confusing, you’ve got to get ascii decimal digits out of fixed byte positions (machine readable what?), and you really need to talk to a cataloger to get to the bottom of “date1” and “date2”, as well as the “date types” and what they mean.
Beware f date type “q”, for “questionable date”, meaning that the publication date is somewhere in in the range of date1 and date2. (These would seem , by examples in the OCLC documentation, to be inclusive boundaries, although the documentation doesn’t actually explicitly say that).
On top of that, dates in date1 and date2 can show up with “u”s in them for unknown digits. “19uu” means sometime in the 20th century.
And in the final note in the this is really meant to be machine readable? column, let’s say you know something was published in the 19th or 20th century. You might think you’d use the “q” date type and put date1=1800 and date2=1999, that would certainly express what you know. But no, the OCLC examples say to put this in as “q” date type, with date1=18uu and date2=19uu. huh?
The other problem with getting dates out of 008 fixed bytes is that since so many of our traditional ILS’s completely ignore them, it’s not clear to me how correct they’ll be, since a mistake didn’t matter much before. But in a testament to years of catalogers entering correct data even though their systems did nothing with it, the data seems at first analysis to be pretty good. I think it’s going to be better than trying to get a date from 260c, especially with the “hebrew date” issue.