[Coco] Y2K fixes ever developed or posted?

[Robert Gault]

Theodore (Alex) Evans wrote:
> 
><snip>
> There are a number of places where the date is used where there is no 
> space for an extra byte.  For example the file descriptor sector 
> (probably *the* most important place to put a time stamp).  In any case 
> OS-9 doesn't use BCD for date storage, one byte can hold 256 values, not 
> 100 and two can hold 65,536 values, not 10,000.
> 
> 

That is true but not quite relevant to my comment. OS-9 time has the 
following structure:
D.Time   equ   .          System Time
D.Year   rmb   1
D.Month  rmb   1
D.Day    rmb   1
D.Hour   rmb   1
D.Min    rmb   1
D.Sec    rmb   1
D.Tick   rmb   1
D.Slice  rmb   1          current slice remaining
D.TSlice rmb   1          Ticks per Slice
D.Boot   rmb   1          Bootstrap attempted flag
(D.MotOn  rmb   1          Floppy Disk Motor-On time out)
(D.ErrCod rmb   1          Reset Error Code)
D.Daywk  rmb   1          day of week, com-trol clock

While the above can keep track of 256 years, it was intended to be used 
as follows, 19xx where xx was determined by the D.Year byte. The obvious 
way to enhance this but slightly harder than adding the value of D.Year 
to 1900, is to create a D.Century byte somewhere in unused OS-9 data space.

With a D.Century byte, the year would be represented as D.Century 
+D.Year. This is not exactly the same a 2 byte D.Year that produces 5 
digits. D.Century+D.Year as used above covers about 25,600 years while a 
two byte D.Year would cover 65,536 years.

I concede that a 2 byte D.Year would work better than D.Century+D.Year. 
Esthetically, I'd prefer either of the above over 1900+D.Year.

The argument that there is no room in the file descriptor for another 
byte is specious. While it would not be backwards compatible, the 
obvious answer is to redefine the file descriptor by increasing the 
number of bytes that represent the year.

While this issue is moot for a Coco, it is not so for our records in 
general. If humanity expects to exist past any particular year, it needs 
to use records that permit representation of that year. Otherwise sooner 
or later (sooner in the case of Y2K) there will be major problems.

What do you think is going to happen in the year 2226 (not that far 
away) if all computer systems stick with the current patches used for 
Y2K of 1970+256 or something similar.

We will all be dead, yes, but I repeat that reasoning is why Y2K 
happened in the first place.