I’m a hardware guy who works closely with software people and I totally agree with all of this.
Thanks guys. I was starting to wonder if I was off base somehow, considering the responses I got to a simple opinion.
A physical flaw in a single unit leading to a boundary error like this, and apparently not causing any other problems, seems pretty damned unlikely. Feb. 29 is a special case that requires special handling and this is exactly the sort of error you’d see if there was an error in that code. It’s also the type of thing that could be neglected during testing.
It is possible that this wasn’t occurring in every car of that model. The manufacturer of that clock unit could have corrected the error at some point and this particular car could have gotten one of the last few of the bad batch, or Hyundai could have changed suppliers partway through the model year.
For all we know, Shoeless may not be the first owner and the clock could be an accessory added by a previous owner.
Here is someone else reporting the same thing on Reddit.
I’ve been in manufacturing for over 25 years and have worked on subcomponents for the automotive industry for over 10 years. That component was made by some subsupplier and could easily has a software bug that was fixed at some point in the run. It’s not a safety issue and almost no one would give a shit enough to complain to the dealer.
Sorry for the double post but the car is identified as a Hyundai Santa Fe.
This is fun. One more from a Hyundai forum in 2005.
Now that last suggestion would be funny too. A useless accessory, that has a bug in it making it even less useful, that was an aftermarket purchase by some schmo who really wanted to see the date at a glance. But not for time travel purposes, as there is no year display.
It all depends on where this date thing is placed. It could be an incidental part of some other more useful thing. For example, is it part of a map light unit that needed to be replaced at some point and was ordered from a J. C. Whitney catalog?
Obviously, from hajario’s links, this was a factory accessory, but it’s not unimaginable that someone could have added such a thing.
There’s a Technical Service Bulletin on the problem, too:
So it’s obviously known to the manufacturer - and whether it’s a “design defect” or a mis-manufactured part, it’s unlikely to be a one-off problem.
[ETA: April Fool’s Day, heh.]
And 2005 wasn’t a leap year. Maybe someone reset it with the wrong year at some point.
Actually I thought your calm and polite response to some uncalled-for snark was really classy. I’m not sure why Rick got so upset - in my experience he’s a great poster and a real asset to the SDMB, so let’s hope he was just having a bad day.
I agree. That was totally out of character for Rick.
Oh man. I mean, I’m a big fan of Rick as a poster as well, but I’m also a big fan of pwnage, and after that speech about 100 years of Hyundai experience, the fact that there’s a TSB about this particularly defect is just too much.
Believe me, I was not feeling calm and polite, especially after his second response. I intentionally did not respond to the second one because my response wouldn’t have been calm and polite.
I considered pitting him, but there have been one or two times when I was having a bad day and responded to someone somewhat snarkily when it wasn’t called for (although I don’t think it rose to the same level) so I’m willing to give him the benefit of the doubt here.
My guess is that it’s a combination of poor design and idiosyncratic glitch. A well-designed piece of software will not only give appropriate output given appropriate circumstances, but will also, as much as possible, give appropriate output given inappropriate circumstances. Ideally, the appropriate response should be to fix the inappropriate circumstances, but at the least, it ought to give some sort of error message.
So you’ve got a date clock that usually works correctly, even during leap years. But occasionally, something funny happens-- Maybe there was a voltage surge in the power system, or maybe the car was left in the garage for too long and the internal stay-alive battery in the clock got drained too far, or maybe it was just hit by a cosmic ray or something. And, where a well-designed clock would be able to recover from the problem that caused, a poorly-designed clock couldn’t.
The appropriate response to finding a value outside of acceptable bounds would be something like what some household appliances do, blink zeros or show a “please reset” message or some-such.
I suspect that these particular clocks don’t ever work correctly on leap years (there may be some that work because they got units with fixed software). What are the odds that something like a power surge coincided with the rollover from Feb. 29 to Mar. 1, and that it happened in more than one car?
I would think that in this case, the logic required to correctly identify the error would be barely less complicated than the logic required to correct it. I.e. Code that does “Oh no, it says Feb 30, and Feb only has 29 days! Must report error condition to the user so s/he can reset me!” might as well be code that does “Oh no, it says Feb 30, and Feb only has 29 days this year! It must actually be Mar 1 – let me adjust that and carry on!”
I concur with your view - this is exactly the sort of thing that happens when a piece of special case handling code has been done wrong for example accidental use of < when > was intended, or != when = was intended.
If the code for this device resides in flash or EPROM, I guess it’s possible that it could be a one-off glitch that happened either when it was being flashed, or could perhaps be indicative of hardware failure of a single memory location on the chip. An unintended change to a single byte of code could potentially do this, without manifesting in any other kind of adverse effect.
The problem with this is that an invalid date could have any number of causes so you can’t say for sure that a value of 2/30 should really be 3/1. When there’s an invalid value the right thing would be to check another source for the correct value rather than trying to deduce it. In this case the easiest second source is the human operator, and the way to access that source is to flash an error message.
I know you agree with me and are just giving a possible alternate scenario.
Certainly it could be a bad bit that just happens to be in code that only executes once every four years. That’s unlikely but possible. But honestly, if Occam’s razor is applicable anywhere, it’s here. We could also hypothesize that hackers are breaking into just this model car and screwing with the clocks in order to intentionally mess up the handling of leap years.
Bumping this because the big day is coming up.