Solaris 2.6 Fixes year 2K probs; does Linux suffer the same probs

Solaris 2.6 Fixes year 2K probs; does Linux suffer the same probs

Post by Geoffrey K Jacobse » Thu, 08 May 1997 04:00:00

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

Anyway The Solaris FAQ:
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 <> 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


Trunked Network Division      +64 3 3581067(voice)  +64 3 3580320(fax)
Tait Electronics Ltd NZ.        LINUX - The choice of a GNU Generation