[Coco] OS9 Level I - Clock issue?
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
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