SUMMARY: 4.0D and Y2K patches

From: Alan Garde <alan.garde_at_transport.uk.eds.com>
Date: Fri, 22 Jan 1999 18:03:10 +0000

The upshot is for 4.0D Y2K compliancy you need to have Patch Kit #3 installed for a fix to strftime(). Although this function is likely to have little effect, as the problem wasn't noticed earlier in Compaq's Y2K testing, if you want to guarantee Y2K compliancy then Patch Kit#3 is a must.

The fix in question is part of a "csh and ksh fixes, security" fix (bizarre I know), and when you start working out what other patches are required to install this, you get about half the patch kit, so we've decided to go with the whole thing, and redo our testing in order to give the customer the best deal.

I had some questions about the location of the Y2K whitepaper that had the comments about 4.0D needing patches added to it, so the whitepaper can be found at:

http://www.unix.digital.com/unix/year2000/whitepaper.html

One thing I will say, it is a great boon now that the TruCluster patches are automatically handled by dupatch. This is great work and makes life a lot easier!


Alan

---
Hello,
We've been operating under the assumption that 4.0D was Y2K compliant, based on the release notes and the whitepaper we read on Digital's website middle of last year.
We've just discovered that this stance has been changed and two problems need to be patched in order to make it Y2K complaint, one for the /usr/bin/at command (fixed in patch kit #2) and one for strftime() (fixed in patch kit #3).  We've done a lot of system/Y2k testing against 4.0D with Patch Kit #2 and are due to roll this out to a customer soon and so are loathe to go to Patch Kit #3 in a rush.
The problem stated in the white paper is:
strftime() (standard C library) 
The strftime() function was displaying incorrect values for the %y (year within century) format specifier only when width
and/or precision modifiers were used (ie: %02.02y) and the year specified was greater than 1999. This has been
corrected. Use of the %y specifier without width and/or precision modifiers remains correct and this is the standard                      usage. The width and precision modifiers are DIGITAL extensions and not part of the UNIX standard. This fix will be
available in the next DIGITAL UNIX Version 4.0D patch kit, scheduled for availability November 19, 1998. 
I know we aren't affected by this in our code, so the question is, does anyone know what will be affected internally in Digital Unix by this?  If it's nothing crucial, we will stick with Patch Kit #2.
thanks,
Alan

Received on Fri Jan 22 1999 - 18:06:22 NZDT