Do you happen to remember what the other change was?

It turns out to be a change to a routine used in the HTTP server for parsing date strings - the old version would, for a 2-digit year, start by assuming that the date is in the current century and:

if the resulting year is more than 50 years ago, assume that it's in the next century;

if the resulting year is more than 50 years in the future, assume that it's in the previous century;

while the new version would follow the X/Open^H^H^H^H^H^HOpen Group Y2K guidelines and treat years 69-99 as 20th century and 00-68 as 21st century.

****Note, though, that none of this represents a claim by NetApp releases between 4.1 and 5.1.2 are Y2K-ready; those releases haven't had Y2K testing done (other than unit-testing of fixes checked into 4.1), so we can't and thus won't make any firm claim that they are Y2K-ready.****

We can, however, firmly claim that releases prior to 4.1 are definitely *NOT* Y2K-ready; in those releases, the code that handles the real-time clock won't treat its 2-digit year value as 21xx if xx is below 70, and the "date" command won't let you set the year past 1999. Fixes to those were checked into 4.1.

In addition, the diagnostic kernel, as Paul noted, also had Y2K problems; I don't know what the consequences of those problems are, but they might be harmful.