So it says your startime clock is 11-Jan-11? So is Workbench and programs showing it as the same year, 2011? And you say it crashes on 2018? Which...actually... in terms of the Amiga it's the 8 digit that makes me wonder if there is indeed an interesting reason behind this. 2018 itself means nothing and that's why it's all weird to me, but the 8 being the end year, like 1978 is the first year, 2078 is the end year. To hell if I know why it would be interesting, but it stands out as less random than it killing itself a year prior.
Does that clock board manufacture have history with PC/DOS hardware by any chance? Hmmm. For it to crash, not even roll over but crash... I mean yeah that's probably the drivers! Wonder if that sucker is doing some messed up math on the driver side in order for the Amiga to get the same year as a PC would read it as? That was the whole Y2K thing, how messed up things could get when the computer suddenly went backwards in time by a hundred years because it rolled over its two digits.
I'll say this, I don't know why, I can't point anybody to the exact reasons, but it may happen that 9 out of 10 clocks released for that machine have issues there, but I don't see how it's the 1000. I don't even have that machine and I'll give it a whole lot more credit than to say there's something wrong on the 1000's end. It's easy to see AMiga 500/2000/1200 and note no such issues with the clock and then to look at 1000, see issues with several clock models, and the temptation is certainly there to say 1000... But unless that 1000 is still running Workbench 1.1 and someone can point to Workbench code as being an issue, a 1000 with Workbench 1.3 should handle the clock no different than a 500 does. Which makes me want to say it might look like a 1000, it might smell like a 1000, but that ain't no 1000 problem!
Backed up clocks counted years from 0-99, that's what they did in general terms at that time. I'm pretty sure some of the parts for the 500 backed up clock could be bought from radio shack, it was super simple clock stuff, cheap but useful, hence we can get away with selling something cheap for a large price tag. I can't imagine the basics of the hardware is any more complicated than battery power going to that simple type of clock processor to keep track of the numbers until Workbench can once again take control.
I guess it's the taking control thing that's the problem here. I had no idea it was so complicated to extract the time from the clock, and would thus require a completely separate loading driver, which is where I bow to real world 1000 usage over my thoughts. But it would make much more sense that somewhere along the line the code for these 3rd party drivers are screwing up the transferring process. A two digit clock year should not crash any computer when it rolls over, there's got to be something with the math in that code that when put into Workbenhh terms crashes the system. I'm a man that knows not the "why" of it all, but it doesn't take a great actor to recognize a bad one, a great programmer to see possible issues with code, and the one thing I am sure of is that the Amiga, all of them, were great machines, and if the 1000 crashes in the year 2018 when a 500 does not, I have to want to believe there's a way to figure that stuff out, because the hard limits have simply not yet been mathematically reached.
That may not change the overlying fact that perhaps a majority of 1000 clocks seem to have issues,,, But its a love for the Amiga in general that makes me ponder it more deeply than simply accepting it as being a 1000 or even a clock hardware/driver issue. Simply not being written to deal with things being more than 20 years into the future... That just does not sound right. That's not how digital stuff works. Yes there's lots of bad programing, and it can certainly be said that many programs did not "imagine" stuff would be working in 20 years, but for a backed up clock to crash a 1000 in 2018... There's an explanation for that which is so much better than bad programmers not being able to see the 1000 in 20 years. On a programing digital level, if it's going to work 10 years from when it was built, it should work 20 years from when it was built. The Amiga could understand this, the backed up clocks hardware itself must understand this if it can go above 1 digit. If it can count to 10 years, it can count to 99 on a hardware level. Crashes happen when math goes bonkers. So this is where I'm sure the actual reason for this crash has got to be much more fascinating than some people seem to think. Issues are one thing, crashes are another, and why does it happen when it happens? I'm not the biggest math guy, but I'm simply saying it's these kinds of weird math issues I find interesting. There's a reason for that crash that's deeper than the people didn't think ahead 20 years, and it would be interesting for me to find out why even though I couldn't do it myself by any means. There's a real reason that if you were told it you and I and everyone would say "oh yeah! of course that's why!" That's the thing I've been lacking in terms of what I've heard from you and others. I'll be honest at first I thought you just didn't have the proper setdate tool. Yeah, I'm an asshole... Yes you have real world 1000 experience, but I have plenty of real world 500 experience and the only thing that felt right in terms of my experience was perhaps you're not looking at what's right in front of you. Apologies there, for now I see your real world 1000 experience includes 3rd party device drivers instead of Workbench's built in stuff. So that's where I bow my head in shame and say sorry I didn't trust you there, but I do feel you of all people should have a little more faith in that old beauty, the 1000, because I'm sure you're right practically, that a whole lot of 1000 clocks have issues, I'm also sure it's not worth finding out the ones that don't, but I'm still left with the same feeling I had prior, nobody is showing me why it can't be done, and thus I assume, and I almost always assume correctly in these situations, that it can in fact be done. Somehow. May not be worth it, but it can be done, somehow someway, somebody out there can get some clock to work on the 1000 that should not have any issues the other Amiga models have with that same operating system. Yes, sometimes crap happens between models when people were not exactly thinking ahead, issues for sure... But if you can't get a game to work on your 2000 or something when it easily works in a 1000, that does not mean it can't work on those machines, it just means you've got to put your thinking cap on. I don't think your 1000 can do anything my 500 can't do, hell, I don't even think it can't do much the 1200 can do, but that goes both ways actually. If my 500 can do it, and in terms of this clock junk it can, my AmigaLove insists that there must be a way, my 500 ain't nothing special in terms of clocks, other than perhaps it got lucky with one direct from Commodore, someone who would hopefully know a thing or two about the hardware.
Are we really thinking a hardware clock developer in 1985 can see no sight lines for the year 2000, but the simple fact that other Amiga models would have the benefit of a clock made in 1990 (I have two, one '87 one '89) makes everything better? The reason someone making a clock wouldn't care about the year 2000 is because when it rolled over to 0 nothing bad happens in terms of the clock. It rolls over, it's two digits, it's now 00, you insert the correct century yourself. As far as I'm aware there's nobody with classic DOS hardware telling people to make sure they keep those dates in the 90's... Could it be that a company making a cheap clock were good enough to think 20 years ahead in terms of that clock, but maybe not so much in terms of others software? If it works 10 years later than the code should allow it to work 20 years later and so on. So why does your 1000 clock crash the machine in 2018? That's where the story is interesting to me, that's where you see possible brilliance from what is on the surface bad coders. It's noteworthy in the bad programing line of thinking to note Commodore themselves had issues with their own setclock tool. A real Y2k issue, as a matter of fact. You couldn't properly set the clock prior to Workbench 2.0 past the year 2000. This was not a Workbench or Amiga issue, it was because setclock was dealing with math, translating 2 digit numbers that the human is thinking of and putting that into Amiga terms. You're saying to set the clock to "99", the Amiga knows that as 4 digit 1999, and tells the backed up clock that it's year 21, 1999 minus 1978. Load up the machine, it gets 21 back from the clock, sets the year to 1999. Problem came from Commodore not adding the correct math once the human was entering "00" meaning for it to be 2000. Your backed up clock views the year 2000 as year 22, if the Amiga gets back 22 from the backed up clock it will set the date to 2000. But the setclock tool was not keeping in mind the math change from the user that was using 2 digits to the Amiga that was using 4 digits and then back to the battery clock which was using digits based off of 1978 as the start year.
So are there real world programing issues? For sure! The Amiga, which should not have had any issues with the year 2000 actually did have a real issue setting the clock prior to Workbench 2.0, which managed to get a late 1997 patch for Workbench 1.3 to fix it! But why was there a problem in the year 2000 for the Amiga? Once you understand the math that is involved in translating that stuff to the battery clock it becomes very clear. While the Amiga and Workbench understood it was the year 2000, the person responsible for writing setclock didn't change the math when the user was going to zeros now. Makes sense, understood. Programing mistake yes, but clear reason why once understood. I think setclock after Workbench 2.0 would use the actual 4 digit years, thus making the math not an issue there. It's 2019? Workbench 2.0 has the user say it's 2019 and the Amiga tells the battery clock to save the digits as 41, 41 years after year 0, which to the Amiga meant 1978. In Workbench 1.3 the user was using 2 digit years, but the Amiga itself still understands the 19 means 2019, setclock however, did not do the math properly.
Math happens, math broke something that was not thinking too far ahead into the future. The issue had no real issues for Workbench 1.3 users, especially since at the time as long as the clock was already set correctly it had no issues loading the correct time. But it's not like setting the date to 00 broke the Amiga, it just screwed up the math and it put out the wrong year. But it's not they weren't thinking into some mystical far away time, in fact they were, they just were not being as careful as they should have been. The math was programed wrong, once an exact moment passed, when you wanted 00 to mean 2000, that's when the math broke, an exact moment in time. The battery clock goes to 99 where it will then reset to 0, at which point the Amiga, despite understanding years above 2078 will now believe it to be the year 1978. Math happened, a precise moment was reached, a 2 digit battery clock reset itself and now your Amiga thinks it means 1978. Digits in form or another got messed up, the entire time the simple 2 digit battery clock in no way was the direct reason for any of these issues, it's simple 0-99 design was actually an asset to the Amiga compared to the PC. Is there a programing issue with some 3rd party 1000 battery clocks? No doubt. But why 2018 for yours? A year that means nothing for the Amiga and nothing for a 2 digit clock. The fact that your clock worked and set the date after the year 2000 correctly at all means it's not a math issue with the changing of the century. If your clock is guilty of not thinking into the future, it should fail at 2000 when the math changes on the Amiga, and eventually the thing itself should roll over when 99 goes back to 00, telling the Amiga the false date of 1978. I mean apparently there's major issues coming in the 2040's when loading the time from the clock from the battery will have issues in getting it precise. I've yet to wrap my head around why that is, but I'm sure there's real math there has nothing to do with the actual battery clock, which if it can count to 10, it can count to 99. It's hard to believe that your 3rd party clock was not thinking ahead and thus in some far away year it simply stopped working, and your luck happened to be in 2018. If they were thinking ahead enough for it to work correctly in 2000, what is it about 2018 that not only causes it to no longer work, but to crash the entire computer? It's math I imagine, but there's got to be an interesting reason it happened in 2018 with your clock.
That's what makes me think about the PC stuff, were the companies that made 1000 clocks doing stuff on the PC end? If you could somehow get the basic clock hardware hooked up to a PC would they read as the same date? That would end up being awful for Amiga users down the line, but fascinating from a company end, don't you think? What extra trickery would need to happen in order for clock hardware to deal out the same time on multiple systems? Would that even be worth it for a hardware company to think about and code for? I could be going way too deep on all that, but it would make more sense to me if the crash was because the internal/driver magic suddenly translated a year to be something that the Amiga itself does not understand. Is it rolling over on the Amiga end, does the Amiga suddenly think it's in the year 4000, much higher, perhaps much lower? Is there some back/forth checking going on and the report back doesn't match?
This dude has no idea other than he wouldn't be surprised that if it were dug into by a capable person that the few who do care about old computers clocks would consider it an interesting read that would indeed be a little deeper than someone thought ahead 10 years but not 20. Computers that did not deal with Y2K did not crash in the year 2000, they just thought it was now 00, the past, 1900 in human terms. Issues related to that were in the programs, not the hardware. Perhaps it's because the Amiga was indeed more advanced on a clock level than PCs were, capable of understanding 4 digit years, I think long past 2078. You can display 3078 on an Amiga I believe, at least with 2.0 and above, Workbench 1.3 would understand those years but you can't set them or see them, it's internal stuff. it's just that it can't load a clock past 2078 because battery clocks only stored 2 digits, thus when the hardware rolls over the Amiga is thus forced back into time, but the Amiga wouldn't roll over to 1978 until you restarted the machine. What's going on with this particular Amiga hardware and its drivers along with the Workbench? In practical every day terms you're right, they probably didn't think ahead in 20 years, but in computer logic, if that thing is crashing... Wouldn't it be cool to find out the Amiga thought the sun was about to explode and that's why the crash is happening?
May not be anything near as awesome as that, but it's something more than bad hardware not thinking ahead 20 years. Two digits in those things, if it can count to 10 years then the hardware can count to 99. There must be a magical clock out there for you, Erick! Or one that has yet to be made... But it's out there, I believe in the power of the 1000! Hell, worth trying out kickstart 1.1/1.2 if by some chance your clock makers were thinking even further into the future than Commodore did! Workbench 1.3 itself needed a patch in 1997 to set the correct year after 2000. It may even be possible, though perhaps not likely, that your 1000's clock 3rd party maker was doing more thinking than Commodore was, making up for whatever issues Workbnech 1.1/1.2 may have had to go beyond 2000, but then Workbench 1.3 may have come along and messed everyhing up for you! haha. Probably not the case, but that's something I imagine most people would never think of but it wouldn't be the first time that actual good programing back in the day that fixed bad programing on the computer's end would end up being fixed later on, making the good programing now look awful. Whatever the reason, there's got to be one, and I bet it's an interesting one!