In article <84slqi$4j7$1 at mach.vub.ac.be> gbottu at bigben.vub.ac.be (Guy Bottu) writes:
> 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 :
[cut]
> case 's': /* short */
> if (timeRec->tm_year >= 100)
> sprintf (timeStr, "%0d/%0d/%0d", timeRec->tm_mon+1,
> timeRec->tm_mday,
> timeRec->tm_year + 1900);
> else
> sprintf (timeStr, "%0d/%0d/%0d", timeRec->tm_mon+1,
> timeRec->tm_mday,
> timeRec->tm_year);
> break;
[etc]
To add to Tim Cutts reply to this, the reason for this bug is the
common misconception that the "struct tm" field tm_year is a 2-digit
representation of the year. It is is labelled in the ANSI C Standard as:
int tm_year; /* years since 1900 */
[ Source: "The Standard C Library" by P.J.Plauger - an excellent
reference book. ]
Hence for 1900-1999 this value has indeed been two digits, but that's
just coincidence. The correct solution is always to use "tm_year +
1900" instead of an "if (tm_year >= 100)" hack. SRS is far from
alone in this problem as it seems most of the minor Y2K bugs spotted
so far have the same route.
James
--
James Bonfield (jkb at mrc-lmb.cam.ac.uk) Tel: 01223 402499 Fax: 01223 213556
Medical Research Council - Laboratory of Molecular Biology,
Hills Road, Cambridge, CB2 2QH, England.
Also see Staden Package WWW site at http://www.mrc-lmb.cam.ac.uk/pubseq/
