[Coco] OS9 Level I - Clock issue?

Gene Heskett gheskett at wdtv.com
Mon Dec 28 14:26:57 EST 2015


On Monday 28 December 2015 12:19:44 William Astle wrote:

> On 2015-12-28 10:06, Gene Heskett wrote:
> > Unfortunately for the hardware clock, we still run into the overflow
> > and wrap back to zero in 2038 because the year byte is just that, a
> > byte whose max value is of course 255 in decimal.
>
> Actually, it would be 2155 in this case, wouldn't it? The year is
> really "years since 1900" (or at least I think that's how it's been
> interpreted these days). No doubt there are older programs that show
> "19115" or "19;5" or just "1915" instead of "2015".
>
> The 2038 wrap-around is applicable to signed 32 bit unix time stamps
> which count seconds since roughly Jan 1, 1970 at 00:00:00 UTC, but
> that doesn't wrap any time in the likely relevant future on systems
> with a 64 bit count.
>
> OS9 (and NitrOS9) don't use the unix time stamp scheme as far as I
> recall so they won't be affected by the 2038 thing. If I recall
> correctly, OS9 actually stores all 6 components of the time/date
> separately in a 6 byte packet.

You are right William, as its been 18 years since I was last kicking that 
codes tires.

However, I will stand by my comments re the reason for the loss of system 
ram compared to about Nitros9-v-1.17 when I could do anything I wanted 
with my machine.  Conditional assembly, pulling in ONLY what that user 
needs to run HIS hardware, should have been the direction development 
went.  Sure, modules are nice, but each one we have to link to eats 32 
bytes of system ram.

Cheers, Gene Heskett
-- 
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Genes Web page <http://geneslinuxbox.net:6309/gene>


More information about the Coco mailing list