Here is a fuller explanation of the three ProDOS/GS.OS Y2K bugs I supplied a fixer for:

All three bugs are code of the type (in english):

Compare to number 100
if larger then subtract 100 and loop back
if less go on (i.e., convert all years to the 0-99 range).

The one in Basic.System just says to display <No Date> when over 100.

The patches just ignore this code entirely.

Well, the basic design of ProDOS gives room for years of 7 bits (a
range of 0-127) and there is no getting around that. The question
is, was it meant to hold only data from 0 to 99?  The old ProDOS
documentation is unclear on that. However tests years ago showed
that ProDOS would indeed insert dates over 99 in the catalog and
they worked. The same is true of early GS/OS. For that reason all my
software assumes use of the range 0-127 meaning that dates are fine
up to 2027.  Basic System did not seem to agree with that, but the
patch, which just removes the compare to 100 code, works fine for
all dates from 1900 to 2027.  The real problem occurred in the
1990's when the code for ProDOS and for GS/OS was modified to insert
the mentioned comparison. What this did was to CREATE a Y2K bug that
did not exist before. The patches just circumvent this.

Of course, this makes the dates go bad in 2028, but I'll probably be
dead then anyway and if there are still working Apple ][s then, that
will be amazing.  (In any case, you could always just reverse the
patches at that point.)  The alternative (not patching) just means,
as all classic Y2K bugs, that all dates fall in the range 1900-1999.
 There are some effects of this. For example my 8 bit software that
displays the day of the week (not provided by P8) does so by
computation using the year, month and day of month. A year of 0
(always meaning 1900) will, of course, compute to the day of the
week in the year 1900 and not 2000. This led some people to think
there was an error in my code - rather it was an incorrect date
produced by ProDOS itself - the patch fixes that.

Of course, it would have been better if Apple had provided more than
7 bits for the year (or had used a later base date), but that is the
way it is and is what we have to live with.  It could very well be
that some programs will have problems with the patches - so whether
to do them is up to the individual.

Be advised that a lot of my stuff will not work correctly in this
millennium without these patches.  (And concerning my own programs,
you should not use 3rd party patches; better, get the current
versions off Bernie ][ the Rescue or get me to upload them, which I
will be glad to do provided a Stuffit archive upload is acceptable.)
The only Y2K bugs I know about in my programs are in Info.Desk
(cosmetic) and in the set date function of Cat.Doctor/Utilities, and
the corrected versions are available.  Mr.Fixit/Volume.Repair does
not have a Y2K bug: it does kill all dates prior to about 1976
(since no Apple existed before then and so those dates are assumed
false - and there were plenty of them). True, without the patches
Mr.Fixit will zero dates prior to '76 (meaning also 2076 since there
is no way to distinguish) but with the patches Mr.Fixit works just
fine as it is.

Glen Bredon