A friend of mine has an old Toyota. This 2000-something Toyota has a clock/calendar. He showed it to me. It displayed things like time, month, day of the week. After 2019, he noticed the day of the week was wrong. So he attempted to adjust it and found the source of the problem. The calendar years only go from 1999-2018. There is no 2019. Fortunately, it doesn’t display the year, so he just set it to another year so the day of the week is correct when viewing it.
As a software engineer, this seems like an odd bug or limit, and I was wondering if anyone knew more about this embedded technology in some cars from early 2000. Many of us remember the Y2K problem. Seems that this wasn’t have been a new concern when it was being developed.
Anyone have embedded software experience to explain this?
It sounds like they might have intended to simply use a perpetual calendar, but skipped a reasonable-sized year table/full algorithm. Maybe the programmer screwed up the algorithm, and the 20-year window is a kludge fix, or was a fan of planned obsolescence. After all, “who drives a 20-year old car anymore?”
These sort of issues makes me wary of upgrading to a newer model. I don’t want a key fob thing. No power windows or door locks. No touch screen display. And on and on.
Why would I need a calendar in the car? It’s just something to break.
You would have thought that after Year 2000 every programmer would have learned his lesson about planning for the future. I think this kind of programming is probably on par with a project for a sophomore CS major.
I have 2007, 2008, and 2012 Toyotas and none of them have anything with the date. What functionality in your car shows the year?
Yes, that’s what I was thinking. Just a matter of programming skills and techniques you wouldn’t impose a limit like this unless there was a good reason for it. I’m not the only one that seems at a loss of why someone would do this intentionally if this is the case.
My friend’s car doesn’t display the year, but it displays the month, day and day of the week along with the time and other functions such as external temperature. You need to set the year correctly so it displays the correct day of the week. Even though the year is not seen. This was likely done to take care of leap year.
It has been a while since I’ve given serious thought about calendar programming since modern programming languages have n extensive time/date library. If this was developed in 1998 or 1999 before it was first put into use, it might be running on a low-cost processor such as a 6502. Likely developed in assembly language and I imagine a limited amount of memory. If that’s so, it might have its own data table for the calendar and not using a full calendar algorithm. Perhaps whoever was doing the software didn’t want to bother with writing a complete calendar function and figured this shortcut for 20 years was good enough.
The other capabilities is that it displays length of trip in minutes (maybe miles too) and some other things I’m not sure what they do. So it could be a space saving decision made.
It would be interesting to know what the actual CPU specs are for what is in this factory installed device. It would be even more interesting to see the source code for it. Although this is unlikely to be easily found. I’ve known software engineers who worked in the gaming industry and did process control stuff, but not anyone I know of who has done embedded devices for cars.
I don’t think it was a question if it was needed, but it was a feature to make that year’s model look more advanced or high tech compared to the others would be my guess.
Car manufacturers are exceedingly cheap when it comes to the electronics/computers inside the car (based on my experience), so it would’t surprise me terribly if they were using a 16-bit system or otherwise imposed some extreme limits from the hardware side onto the software developers.
And while I only ever worked on a small programming project at Hitachi, when I lived in Japan, and my experience was mostly at small companies that you have never heard of, I got the distinct impression that Japanese programmers are really bad at their job. They don’t have a good culture for self-learning, experimenting, asking questions, reviewing code, etc. Granted, that might have changed since I was there, but at the time your car was made it would have been the case.
Between the two, I’d probably say that it’s more likely that it was a programmer error of some sort. I don’t see any representation of time that maps to any binary representation of a length that would make sense to use. If they were using binary-coded decimal systems, then it should either poop out at 16 or 32 years not 20. Otherwise, if they’re using a timestamp of some form, neither minutes, seconds, nor milliseconds lines up with any 8-bit byte boundary, at the 20 year range. And by 2000, I doubt that anyone would be making any hardware that’s not using 8-bit bytes.
Anyways, maybe there’s a firmware update? You should check if your car has one.
Wait several more years, then report back. I suspect the car in the OP is older so you haven’t had a chance to hit the problem yet. (Or you could roll the date forward to key dates like Dec. 31 or Feb 28 and wait a few days to see what happens.)
I don’t think anyone’s bothered dealing with the upcoming Unix Epoch Fail in 2038. That’s still far enough into the future that it is officially someone else’s problem. Any non-universal solution will cause code issues now…
If I was a lazy programmer with no long-term prospects with the company, I wouldn’t bother to write code that figures out leap-years and days of the week. I would just program in a simple table or elseif structure that describes year, first day of week, leap year or not. And since I’m particularly lazy, I would do it for just 20 years.
It’s hard to catch this in QA and testing, although in code review it would stick out like a sore thumb but not all software development has the code review stage.
Exactly. Who needs a starter motor when a hand crank will do? It’s just one more thing to break! It’s the same with anti-lock brakes, no?
You can indulge Luddite impulses all you want, but at this point, you’ll have a very hard time finding a new car without the cheap, basic electronic features of which you’re so disdainful. So you’re looking at buying a car that was produced no more recently than the late 1990s. There’s nothing wrong with that, but you should be aware that safety features have come a long way in the last twenty years.
New cars are significantly safer than old ones. If your self-satisfaction at rejecting key fobs outweighs your own interest in car survivability, hey, that’s your call.
Is your objection to cars that are hard to repair? Or is it to cars that have features beyond what you deem necessary for yourself?
I’m asking because this particular “broken thing” is trivially easy for the owner to repair, which is exactly what edwardcoast’s friend has effected. From a repairability standpoint, I don’t really see a problem here.
Good grief. Get a grip on yourself. None of the “extras” I mentioned affect safety or how the car itself operates!
I am an ex-Computer Science professor. I am hardly a Luddite! But I do know when tech is helpful and when it’s just “sparkly lights” to draw in the rubes.
If I lose a set of regular keys it’s a few dollars to get a replacement. If I lose a key fob (which takes up a lot of space in my pocket) it costs real money to replace. And I have no need for it at all.
Note also that these key fobs reduce security and make it easier for car thieves. As noted, car makers cut way too many corners and these are all too easy to hack. There are rings out there that specialize in driving off with expensive cars using simple boxes ordered from China.
For my car stereo, I have a microSD card in it. It plays my music only. The only controls I regularly need are volume and the FF/RW. These are physical (knob/buttons) which I can use without taking my eyes off the road. Not so on most touch screen “centers”.
I just can’t think of why this would be the lazy way. You don’t figure this data out for yourself. Even in 1999, perpetual calendar information was available online. The data conveniently fits into four bits, even allowing leapyear or not to be a single bit, so we’re talking minimal amounts of storage.
I would actually guess an overly complicated table that checks every single date for the day, coded by hand. That’s not lazy. It’s stupid.
Now that you mention it, I distinctly noticed the display was limited to only 4 digits for the year. What do they expect to happen in the year 10,000, just throw away a working car?
Stupid and lazy to not look for other solutions perhaps. I can’t help from being curious to know exactly what the technology is for this, such as the processor and amount of memory. As a software developer, I never looked to reinvent things unless there was a good reason for it. Hard to believe this task was given to one person and no one else paid much attention to it. But since it wasn’t safety related, it might have gone unnoticed until people complained or they realized it later on for it to appear in the manual as having a 2018 limit.
I imagine this was written by a contractor for them, who bragged to everyone he wrote the code for this new calendar feature in the Toyota. Now that this bug has reared its ugly head, people who know him must ask him about it. Like coming up to him at parties asking, “Hey, is it still 2018?”.
To me it was more than, “who is going to be driving this car in 20 years?”, but do we want to establish good technology we can bring forward in our development for future products without having to revisit it each time. But they might have the attitude that with each new car design, they write new code with a new set of developers.
It’s a known issue in the 2000 Toyota Avalon. The recommended fix is exactly what your friend did: set the calendar to 2002.
It’s a 19-year-old car. Probably a 20-year-old car, in fact, given how US model years work. I don’t think it’s unreasonable for Toyota to not really give a shit about whether their calendars work for the fifth owner of their vehicles. Y2K was a problem because lots of things (like bank software) depended on the year being correct in order to function correctly. In this context, we’re talking about a function so unimportant that virtually no other vehicle has it (and the ECU and other important electronics don’t care what year it is).
A former CS prof? Oh, man, that’s the problem right there! You stopped learning after you mastered FORTRAN. TAPE5=INPUT, TAPE6=OUTPUT, etc. Late at night, you go into your garage and fire up your 029 Keypunch machine and have a specially built-in RS-232 interface to your IBM 386 PC running DOS.
But it is important to the owner, because this displays to anyone using the car. So if it shows Month, Day and the wrong day of the week, everyone notices. It makes the company look bad. Not everyone is a software engineer to understand and perhaps even sympathize with the technical aspects of this. All the consumer knows is, “this stupid thing doesn’t work right and there is no fix for it!”. People have posted about this problem I see in social media elsewhere. I’m sure asking what someone in sales and marketing for the company doesn’t like this, they wouldn’t have a “I don’t give a shit attitude”. If they really didn’t give a shit, they wouldn’t have put this feature in to begin with. This is a very visible feature in the car. Even in 1997 or 1998, Toyota already had a history of people using their vehicles for a very long time. A problem like this, whatever the cause or thinking behind it doesn’t make the company look good. It is the “I don’t give a shit” attitude which got us all into the Y2K problem to begin with, they continue to carry forward into development a problem which was coming to come around to bite everyone in the ass and it did. The cause is largely the absence of Best Practices.
