Y2K and SRS

[Tim Cutts]

In article <3871EA79.7864AE37 at genedata.com>,
Tim Eyres  <tim.eyres at genedata.com> wrote:
>Guy Bottu wrote:
>> 
>>         Dear fellow SRS server managers,
>> 
>> The much discussed Y2K bug has hit SRS. SRS 5 servers display that certain
>> databank has been indexed on 03-Jan-19100. This is not a great problem, since
>> it does not interfere with the functionality of the software. I found a fix :
>
>Does this affect only the display of the indexing date? Are there any
>effects when searching entries by date or indeed displaying an entry
>which has a date in the year 2000?

Displaying yes, and that's what Guy's and my fix addresses.  Indexing
and searching, no.  SRS stores the date in a format which is not
susceptible to the Y2K bug.  However, there may be Y2K bugs in some of
the Icarus parsers when parsing date fields in the original flatfiles.
It rather depends on whether the original flatfiles ever used two digit
dates.  I expect few of them do, but it's worth checking.

I've counted 53 date handling productions in the .is files on my system.
I suppose I really ought to check they're all Y2K-compliant...  sigh!

For example, genbank's date parser breaks on 2 digit dates:

  datenum:  ~ {init {$month={JAN:1 FEB:2 MAR:3 APR:4 MAY:5 JUN:6 JUL:7
AUG:8 
                            SEP:9 OCT:10 NOV:11 DEC:12}}}
              /.+ ([0-9]+)-([A-Z][A-Z][A-Z])-([0-9]+)/ 
              {$dateval=$1 + $month.$2 * 100 + $3 * 10000} 
            ~ 

However, since Genbank flatfiles never contain two digit dates, this is
probably fine.

If you're paranoid, you can patch it thus:

--- genbank.is.orig     Tue Jan  4 13:42:34 2000
+++ genbank.is  Tue Jan  4 13:46:02 2000
@@ -71,7 +71,13 @@
   datenum:  ~ {init {$month={JAN:1 FEB:2 MAR:3 APR:4 MAY:5 JUN:6 JUL:7
AUG:8 
                             SEP:9 OCT:10 NOV:11 DEC:12}}}
               /.+ ([0-9]+)-([A-Z][A-Z][A-Z])-([0-9]+)/ 
-              {$dateval=$1 + $month.$2 * 100 + $3 * 10000} 
+              {
+               $year = $3
+               if:{$year<100} {
+                 $year += 1900
+               }
+               $dateval=$1 + $month.$2 * 100 + $year * 10000
+             } 
             ~ 
   des:      ~ {$In:[fields c:def] $Out} tag (iword {$Uniq} | /./)* ~
   acc:      ~ {$In:[fields c:acc] $Out} tag (iword {$Uniq} | /./)* ~

This is still not quite perfect; it won't catch really bogus dates like
563 (did anyone produce any sequence that year? :-) ), but I think the
chances of errors like that getting through are slim.

For the ultra-paranoid, the following patch is the same fix, but prints
warnings for years before 1800:

--- genbank.is.orig     Tue Jan  4 13:42:34 2000
+++ genbank.is  Tue Jan  4 13:51:24 2000
@@ -71,7 +71,19 @@
   datenum:  ~ {init {$month={JAN:1 FEB:2 MAR:3 APR:4 MAY:5 JUN:6 JUL:7
AUG:8 
                             SEP:9 OCT:10 NOV:11 DEC:12}}}
               /.+ ([0-9]+)-([A-Z][A-Z][A-Z])-([0-9]+)/ 
-              {$dateval=$1 + $month.$2 * 100 + $3 * 10000} 
+              {
+               $year = $3
+               if:{$year<=1800} {
+                 if:{$year<100} {
+                   $year += 1900
+                  }
+                 else
+                 {
+                   $dp:"+++ Probable bogus year ($year)\n"
+                 }
+               }
+               $dateval=$1 + $month.$2 * 100 + $year * 10000
+             } 
             ~ 
   des:      ~ {$In:[fields c:def] $Out} tag (iword {$Uniq} | /./)* ~
   acc:      ~ {$In:[fields c:acc] $Out} tag (iword {$Uniq} | /./)* ~

Equivalent changes could (and probably should) be made to all your .is
files.

Tim.