Y2K and SRS

James Bonfield jkb at mrc-lmb.cam.ac.uk
Tue Jan 4 08:56:04 EST 2000

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 :


>  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;


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 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/

More information about the Bio-srs mailing list