[RT17143] Added bogus date values for bad data
authorLiam Whalen <liam.whalen@bc.libraries.coop>
Tue, 27 Oct 2015 23:40:07 +0000 (16:40 -0700)
committerLiam Whalen <liam.whalen@bc.libraries.coop>
Tue, 27 Oct 2015 23:40:07 +0000 (16:40 -0700)
If the MARC has bad data even after filtering by regex, we now use two
different intentionally bad dates to help us locate this bad data after
the update.  In this case we use 000123 for 008/00-05 and 0011 for
008/07-10.  It is possible that our SQL that returns bade date1 values
returns a value with a valid 260 $c but an invalid $264 $c.  In this
case, the code will use the invalid $264 $c.  However, the checks
required to filter out this invalid $264 $c is too complex, so we add
sanity checks after our new dates are created to ensure they are the
correct length, and we use the bogus dates if they are not.  In the case
of bad 008/00-05 there might be a biblio.record_entry item with a bad
create_date, so we use 000123 to identify that.

Signed-off-by: Liam Whalen <liam.whalen@bc.libraries.coop>
data_cleanup/date1/date1_cleanup.pl

index 968b903..faab26f 100644 (file)
@@ -81,6 +81,13 @@ sub clean_date1_records {
 
         my $date_entered = "$year$month$day";
 
+        if (length($date_entered) < 6) {
+            #We will use this bogus date entered
+            #to allow us to easily identify
+            #bad 008/00-05 create by this update.
+            $date_entered = '000123';
+        }
+
         my $field_260 = $marc->field('260');
         my $field_264 = $marc->field('264');
         my $pubdate = '';
@@ -95,6 +102,14 @@ sub clean_date1_records {
             
         $pubdate =~ s/.*(\d{4}).*/$1/;
 
+        if (length($pubdate) != 4) {
+            #We will use this bogus pubdate
+            #To help us identify any records
+            #that had 260 or 264 $c values 
+            #less than 4 digits
+            $pubdate = '0011';
+        }
+
         my $field_008 = $marc->field('008');
 
         my $data_008 =  $field_008->data();