[Coco] Y2K fixes ever developed or posted?

Robert Gault robert.gault at worldnet.att.net
Mon Dec 15 08:21:25 EST 2003


Theodore (Alex) Evans wrote:

> On Dec 14, 2003, at 2:13 PM, Gene Heskett wrote:
> 
>> Unforch, the architects of OS9 did not leave room in that 6 byte field
>> that contained the hex version of the date/time for a carry bit, or a
>> century byte.  So we had, at least for os9-6809, to cobble up
>> something that would work until the coco (and all its friends) was
>> well and truely dead.  OTOH, there was no reason the year field  byte
>> couldn't contain a value above $63, so we used that in most of our
>> fixes.  Those are good till 2079 in my fixes, by which time I'll
>> probably be in the ground for 70 years or so (if I'm lucky that is)
>> After that, well,,, shrug.
> 
> 
> That six byte field for the date is good until *2155* without any 
> changes, or 2027 if you insist on looking at it as a signed value.
> 
> 
It is amazing how the same arguments show up over and over with no one 
learning from past experience. The reason we had a Y2K problem to begin 
with is exactly because people said the equivalent of, "I'll
probably be in the ground for 70 years or so..."

Extending an inadequate technique for a few more years should not be 
dignified by calling it a fix. Postponing the inevitable instead of 
removing it as a possibility should only be used during the time period 
a true fix is being implemented.

With the trivial addition of a century byte to the OS-9 defs structure, 
the OS-9 software clock would be good to the year 9999. If that's not 
good enough two bytes should more than cover the collapse of our 
civilization.

Unfortunately, hardware clocks available to the Coco probably can't 
handle more than the four year leap year issue. That's not good enough 
for 10,000 years. Still you could setup an alarm to remind yourself to 
correct your date at 100 and 400 year intervals.




More information about the Coco mailing list