Internally, Solaris maintains time as the number of seconds since 1970-01-01 00:00:00 UTC (not counting leap seconds). This counter won't have any problem with dates in the year 2000; since it is maintained as a 32-bit signed integer value, it will work correctly through 2038-01-19 03:14:07 UTC, by which time Solaris (if it still exists) will have upgraded to a larger counter.
Though the Solaris kernel itself shouldn't have any problems with the year 2000, applications themselves may have problems, partly because some application writers unwisely chose to represent dates using two-digit years, and partly because some application writers mistakenly thought that localtime returns the year modulo 100, when it actually returns the year minus 1900. These kinds of problems are rarer in Solaris than with typical mainframe applications, but they sometimes do occur.
A year 2000 project at Sun plans to review all libraries, unbundled software, and some 3rd party apps in search of potential year 2000 problems, so that they are resolved well before the big day. Sun plans to make Solaris 2.6 year-2000 compliant when it is released. It also plans to issue patches for Solaris 2.5 and 2.5.1 by 1997-09-30, and for Solaris 1.1.1, 1.1.2, 2.3 and 2.4 by 1997-12-31.
Sun-maintained Solaris applications with known year-2000 problems as of Solaris 2.5.1 (unpatched) include the following.
* SCCS files store only the last two digits of the year, so SCCS stops working after 1999. Sun plans to work around this problem by having SCCS interpret two digit years to be in the date range 1969-2068; this means the revised SCCS will stop working after 2068.
* The Solaris 1 `date' command can't set the clock past 1999. This bug is partly fixed in Solaris 2 `date', which supports both 2-digit and 4-digit years; however, in Solaris 2 you should use 4-digit years when setting the date, to avoid some remaining bugs with 2-digit year handling.
* The following programs are known to have minor bugs related to using year-1900 instead of year modulo 100 when generating diagnostics, temporary file names, and the like:
atq fsck listen passwd sar timex ufsdump uucico uustat uuxqt xterm
* The -me, -mm, and -ms troff macro packages all assume that the current date is before January 1, 2000.
* `sortbib' mishandles bibliographies containing 2-digit years that span the year-2000 boundary.
* `ckdate' rejects years after 1999.
* Problems have been reported with installing Solaris on machines whose hardware date is past 1999.
* The filemgr `find after' and `find before' operations have only 2-digit inputs for years, and mishandle dates after 1999.
* cm (the calendar manager) mishandles dates after 2000-02-29.
* In Openstep, NSCalendarDate, NSDate*, Mail, and Prefrence need enhancements and fixes for years past 1999.
In addition, user applications that invoke `getdate' and `strptime' on 2-digit years are advised to check their assumptions carefully.
Patches for year 2000 problems will be made available for all releases not EOLed at January 1, 1995, in keeping with the 5 year support window. This includes the Solaris releases 2.5.1, 2.5, 2.4 and 2.3 as well as SunOS 4.1.3_U1 and 4.1.4.