Insider clock
14 messages in this thread
I've run into a problem with the clock software from my Insider – it's reading
the correct hardware clock date but setting the system to the previous day's
date. This started occuring on Jan 1, 89. My clock software dates back to
early 87. If you don't have a fix for this problem, it's not serious to me as
I have switched over to my Supra clock which does read correctly.
Thank you, Fred
Fred,
That problem has (had better have been!) been resolved. I'll see if I
can't post the correct software, or at least direct you to where it's available
from.
Sorry for the inconvience.
-Dean
Whoops. Dean, mine says it's yesterday, too. I'd greatly appreciate it (as
would others, I'm sure), if you'd post a corrected version.
Jon
Jon,
Sorry Jon, (and all). My development machine is down right now, but I'll
get it fixed and post it hopefully tomorrow. (now if the SYSOP's would tell me
where I should put it…)
-Dean
Dean, best place would probably be LIB 6 "Hardware" .
Marlene
Marlene,
Thanks, It'll go up tonight. A complete re-write, using Lattice's time
conversion code instead of my own. That way, if it's wrong, I can blame
Lattice! 8)
-Dean
I'm having the same type of problem.
My Insider clock was set correctly to January 1st, 1989, but the Amiga system
software "thought" that the date was the day before–December 31, 1988! By the
way, I'm not the only one here in Vancouver with this problem: at least four
other A1000 owners whom I know have this problem.
For now, I've solved the problem by setting the Insider clock to tomorrow. The
Amiga then "thinks" the date is today. That is, I've set the Insider to
January 3, 1989 (it's January 2 now), but when I copy a file, for example, the
file's timestamp (January 2, 1989) is correct.
I'm not too happy with this stopgap measure, though.
I'm beginning to find the current situation very humorous with all of the date
problems showing up everywhere! – the 1.3 list command, DiskMaster, and now the
Insider clock program. Hopefully we'll see a fix soon!
Fred
<Chuckle> There ARE advantages to being paranoid, one of which is you tend
to run date utilities out to about the year 2500 to be sure all the leap years
and such line up. I'm _pretty_ sure my REMIND utility doesn't have a date bug
for that very reason. Seems A LOT of people have had problems starting with
January 1, 1989; apparently quite a few programmers didn't know how to deal
with leap years… like 1988 (I didn't either, but I beat on it until it
submitted).
Funny. If YOU wrote a calendar or date program, wouldn't you at least run it
forward and backward a few years to make sure it worked? (Dean, no reflection
on you guys… a huge percentage of programs apparently have this problem.
Boy, wait for the fireworks on January 1, 2000…)
Rick
My friend with an Epson Equity had a clock problem on Feb 29, 1988, so its not
just us with the leap year quirks! Ours seem to be showing up at the end of
the year instead. Oh, well.
Fred
Rick, how did you know! While experimenting with a program of mine a couple of
months ago, I found out that it would guru on 1.1.2000! I have since tested my
date routines all the way to 2500. Now, the AmigaDOS 'date' command only
allows dates upto 31-dec-2049. (I think) so I should be safe. 🙂
Khalid.
Rick,
I did check out leap years, the year 2000, and many other things as well.
I really can't understand what happened to the code. It does seem as though,
every time I fixed one type of obscure bug, another one would creep in. The
last one was Jan and Feb of a leap year would be off by a day.
I fixed it this time though. I scrapped my own routines, and am using the
Lattice builtin date conversion utilities. So if a bug shows up again, blame
Lattice. ;^)
-Dean
"It does seem as though every time I fixed one type of obscure bug, another one
would creep in."
Amen. 8)
Rick
Don't forget to add ZOO to the list