[2021] in Release_7.7_team
IRIX Y2K (really leap year) mktime() problem
daemon@ATHENA.MIT.EDU (Robert A Basch)
Wed Dec 29 15:13:45 1999
Message-Id: <199912292013.PAA11485@aupair.mit.edu>
To: release-team@MIT.EDU
Date: Wed, 29 Dec 1999 15:13:38 -0500
From: Robert A Basch <rbasch@MIT.EDU>
While looking at the SGI Y2K compliance web site, I noticed the
following problem report on the mktime() C library function:
Problem Description:
When a user calls the mktime routine with values that are
outside of the normal range, mktime will normalize the
date to the appropriate range (for example: Jan 32 would
be normalized to Feb 1). If the total of the second,
minute, hour and day fields is equal to or greater than
one year and the normalization would cause a change in
leap year state, then it is possible the results can be off
by one day. (As an example: Mar 366, 1999 should be
normalized to Feb 29, 2000, but this bug would cause
the result to be Mar 1, 2000.) This can happen any time
the normalization causes it to cross between a leap year
and a non-leap year (in either direction).
Maintenance Release:
For systems running IRIX 6.5, be sure that the IRIX 6.5.4
overlay or its successors is installed.
Workaround:
This problem occurs when users are calling the mktime
library routine with "out of range" values. Most system
utilities that use the routine do bounds checking before
they issue the call. The work around for this problem is
to ensure that the mktime library routine is called with
"in range" values. (See the mktime(3C) man page for
valid ranges.)
Given that there does not seem to be a patch for this bug, and its
most likely minor impact, there is probably nothing we want to do
about it except note it.
Bob
