Summary: | fix_unimarc_100 could be improved with 210$d values | ||
---|---|---|---|
Product: | Koha | Reporter: | Paul Poulain <paul.poulain> |
Component: | Command-line Utilities | Assignee: | Galen Charlton <gmcharlt> |
Status: | NEW --- | QA Contact: | |
Severity: | minor | ||
Priority: | P5 - low | CC: | januszop |
Version: | Main | ||
Hardware: | All | ||
OS: | All | ||
Change sponsored?: | --- | Patch complexity: | --- |
Documentation contact: | Documentation submission: | ||
Text to go in the release notes: | Version(s) released in: | ||
Circulation function: |
Description
Paul Poulain
2013-05-29 13:26:37 UTC
Or I would suggest to consider keeping (transferring to the new 100$a) bytes 100$a/08 and 100$a/09-12, if 100$a/08 contains a meaningful code for the date and 100$a/09-12 looks like a date (i.e. 4 digits, forming a number greater or equal than, say, 1455 and lesser or equal the current year). What do you think? I agree with the idea of keeping the value if it's meaningful. What does meaningful mean though ? I would say "keep 9-12" if they contain only 4 numbers How about something in this style: my $string = marc->subfield('100','a'); my $s100a08 = substr($string, 8, 1); my $s100a09_12 = substr($string, 9, 4); my $year_now = POSIX::strftime("%Y", localtime()); if ($s100a08 =~ /[abcdefghijku]/ && $s100a09_12 =~ /\d{4}/ && $s100a09_12 >= 1455 && $s100a09_12 <= $year_now + 1) { # +1 just in case the is a next year date on the document # keep the date as $s100a08 . $s100a09_12 } else { # don't care about pub date from 100 -- it does not make sense, try to reconstruct it from 210$d } (In reply to comment #3) > How about something in this style: sounds good > if ($s100a08 =~ /[abcdefghijku]/ && > $s100a09_12 =~ /\d{4}/ && > $s100a09_12 >= 1455 && > $s100a09_12 <= $year_now + 1) { # +1 just in case the is a next year date I really love the >= 1455 :D :D (In reply to comment #4) > I really love the >= 1455 :D :D Oh, yes, I know, I am sorry--it is very exclusive and europocentric... but not as much as the line 661 in the present version of the script ;^) Now seriously: I did not make an experiment but while flicking though the code it seems to me that the function in question is executed both for bibliographic adn authority records. If that was the case one should keep in mind that field 100 in UNIMARC authorities should be of the length of 24. So now field 100 in authorities would be always destroyed and incorrect in the zebra copy of the database... Could you confirm or deny my intuition? |