[6737] in Kerberos
Date/time patch for Digital UNIX (fwd)
daemon@ATHENA.MIT.EDU (Randall S. Winchester)
Thu Feb 22 21:55:15 1996
Date: Thu, 22 Feb 1996 21:41:13 -0500 (EST)
From: "Randall S. Winchester" <rsw@eng.umd.edu>
To: kerberos@MIT.EDU
For those of you with Alpha Kerberos servers and clients who intend to
keep their time in sink. This requires a new kernel.
Randall
---------- Forwarded message ----------
Date: Fri, 23 Feb 1996 13:00:12 +1100 (EST)
From: CSC UNIX support account <CSC@redbck.stl.dec.com>
To: alpha-osf-managers@ornl.gov
Cc: Allan Small <small@redbck.stl.dec.com>
Subject: Date/time patch for Digital UNIX
Dear OSF managers,
A number of timekeeping problems have recently been identified and
fixed in Digital UNIX. Due to the urgency of these problems, the
Sydney CSC has made the patches available on the internet at:
ftp://gatekeeper.digital.com.au/incoming/clock_patches_update/
Without this patch the following behavior will be observed:
1) The 'date' command rejects February 29, 1996 (or any other leap
year) as a valid date.
2) When the system time is changed with the 'date' to any date in March
of a leap year and then rebooted, the system clock will lose
one day.
The first problem is the result of the libc routine strptime not recognising
February 29th of a leap year as a valid date. The 'date' command makes use
of strptime in the processing of the time. The problem is fixed in Digital
Unix V3.2c and later and corrected by patch OSF300-234 for V3.0, OSF305-234
for V3.0b, OSF-320-214 for V3.2, and OSF3250-32191 for V3.2b. These are
already available from the CSC, unfortunately, the README documentation does
not point out the implication of this defect.
The second problem is the result of an improper check for February of a leap
year in the kernel routine resettodr which is found in the kernel module
clock.c. The uncorrected routine will fail to add a days worth of seconds to
the TOY clock during the month of March of a leap year when adjustment to the
system time is made. USEG has prepared an interim fix for this problem.
Corrections for V3.0, V3.0b, V3.2, V3.2b, V3.2c and V3.2d can be found in:
ftp://gatekeeper.digital.com.au/incoming/clock_patches_update/
Regards
Allan Small
Principal Software Specialist
Digital MCS
