Y2K bug in Solaris?!?


I was shocked to find a Y2K bug in Solaris 9, half a decade after Y2K, but I don’t know how else to explain this….

The following program prints a date with a year in 1905 under Solaris 9. Under Linux it displays a date of 2005, and my reading of strptime specification, as well as the Solaris 9 man page, indicates that strptime %Y is supposed to parse a 4 digit year correctly. Given Sun’s repeated claims of Solaris being a more professional/standards-compliant system than Linux, this sort of bug is rather surprising.

Can someone with access to Solaris 10 try running this program, and perhaps on other Unix systems? I’m curious what folks find…

#define _XOPEN_SOURCE 500 /* for inclusion of strptime() */
#include <stdio.h>
#include <unistd.h>
#include <stdlib.h>
#include <string.h>
#include <time.h>

int main(int argc, char **argv)
{
        struct tm       ts;
        time_t          t;

        memset(&ts, 0, sizeof(ts));
        strptime("200505071230", "%Y%m%d%H%M%S", &ts);
        t = mktime(&ts);
        printf("Time is: %sn", ctime(&t));
        return 0;
}

EDIT: I’ve changed the above posting to match the version of the program where I first detected the problem. The first argument to strptime was “20050507123005”. It is now “200505071230”. That is, not including the seconds (“05”) makes all the difference, and causes the bug to show up. Apparently Solaris adjusts the tm_year after it finishes the full converstion, and if there are insufficient characters in the input string to fulfill all of the conversions specified in the format strong, tm_year gets left with only the last two digits of the year. A review of the relevant SUS specification doesn’t show any justification for this behavior.