by Solaris Suffers from a number of year 2K problems.
I know there has been a lot of discussion with linux and the year 2K
problem so I hope I'm not bringing up something thats already been
discussed.
Anyway The Solaris FAQ: http://www.wins.uva.nl/pub/solaris/solaris2
highlishts a number of unix applications that suffer from year 2K
problems. Have the problems been addressed for the linux equivalents?
Here is an excerpt from the FAQ
---
*6.26) Does Solaris have problems with dates in the year 2000 and after?
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
withthe 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 <http://www.sun.com/y2000/> software, and some 3rd party
apps in search of potential year 2000 problems, so that they are
resolved well before the big day.
Sun-maintained Solaris applications with known year-2000 problems
as of Solaris 2.5.1 include the following; these problems should
be fixed in Solaris 2.6.
* SCCS files store only the last two digits of the year, so SCCS
stops working after 1999. Fixing this requires coordination with
other SCCS vendors.
* 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.
--
Trunked Network Division +64 3 3581067(voice) +64 3 3580320(fax)
Tait Electronics Ltd NZ. LINUX - The choice of a GNU Generation