[Coco] Y2K fixes ever developed or posted?

[Theodore Evans (Alex)]

On Dec 15, 2003, at 6:20 PM, Robert Gault wrote:

> 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.

Since the file descriptor is the primary place where the date would 
actually be preserved for the future there not being room there is 
hardly specious.  I guess that one could reduce the maximum number of 
segments in a file to 47 and grab five bytes that way.  The last 
segment being the location used.

> 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.

We are talking about the issue as relates to the coco.  If we were 
talking about UNIX systems, the fact that signed 32-bit dates overflow 
in 2038 and unsigned in 2106, however that system is already in the 
process of being supplanted by 64-bit dates which will not overflow 
until around 292,277,026,596 A.D.

> 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.

If you are worried about a date system being sufficient that it can 
continue to be used into the foreseeable future overflowing in the year 
10,000 A.D. may not be sufficient.  There are calendar systems in use 
that are already over halfway there.  While it is very likely that our 
date system will have changed by then, it is hardly a foregone 
conclusion.