[Bug 10377] New: fix_unimarc_100 could be improved with 210$d values
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=10377 Bug ID: 10377 Summary: fix_unimarc_100 could be improved with 210$d values Classification: Unclassified Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: minor Priority: P5 - low Component: Command-line Utilities Assignee: gmcharlt@gmail.com Reporter: paul.poulain@biblibre.com The misc/migration_tools/rebuild_zebra.pl script includes a fix_unimarc_100 sub. This sub rewrites 100 field in case it has an invalid length. However, the copyright dates, that are stored in 210$d are also in 100, positions 9-12 Koha could try to retrieve the 210$d values in case the 100 must be rebuilt because it's wrong. -- You are receiving this mail because: You are watching all bug changes.
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=10377 Janusz Kaczmarek <januszop@gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |januszop@gmail.com --- Comment #1 from Janusz Kaczmarek <januszop@gmail.com> --- 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? -- You are receiving this mail because: You are watching all bug changes.
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=10377 --- Comment #2 from Paul Poulain <paul.poulain@biblibre.com> --- 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 -- You are receiving this mail because: You are watching all bug changes.
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=10377 --- Comment #3 from Janusz Kaczmarek <januszop@gmail.com> --- 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 } -- You are receiving this mail because: You are watching all bug changes.
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=10377 --- Comment #4 from Paul Poulain <paul.poulain@biblibre.com> --- (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
-- You are receiving this mail because: You are watching all bug changes.
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=10377 --- Comment #5 from Janusz Kaczmarek <januszop@gmail.com> --- (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? -- You are receiving this mail because: You are watching all bug changes.
participants (1)
-
bugzilla-daemon＠bugs.koha-community.org