Y2019 software bug in Toyota clock/calendar

[Unpronounceable]

Y2K wasn’t because of “I don’t give a shit” - it was because “nobody’s going to be using this program in 20+ years*” and “computer memory/storage is incredibly expensive**, so I’ll only use 2 digits instead of 4.”

*Nobody thought banks were going to be using those old COBOL programs for as long as they did. But they just kept kludge-patching the old spaghetti code, rather than rewriting.

**It used to be, at least - I can get a terabyte of hard drive space now for less than I spent on my first 20 MB hard drive…and that’s without adjusting for inflation.

[Really_Not_All_That_Bright]

@edwardcoast

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.

We’re straying into GQ territory here, but I can assure you Toyota doesn’t look bad because it has enough 20-year-old cars on the road for people to notice their calendars aren’t perpetual. The average life expectancy of a new car is eight years or 150,000 miles.

[edwardcoast]

@Unpronounceable

Y2K wasn’t because of “I don’t give a shit” - it was because “nobody’s going to be using this program in 20+ years*” and “computer memory/storage is incredibly expensive**, so I’ll only use 2 digits instead of 4.”

*Nobody thought banks were going to be using those old COBOL programs for as long as they did. But they just kept kludge-patching the old spaghetti code, rather than rewriting.

**It used to be, at least - I can get a terabyte of hard drive space now for less than I spent on my first 20 MB hard drive…and that’s without adjusting for inflation.

Which means they “didn’t give a shit”. Yes, there can be real limits, and there can be work-arounds to those limits. I’ve been doing this long enough to know when there were practical limits on the number of records a system could handle in a database, but I found a work-around to be able to extend this capability before I was thinking about the future, cause I gave a shit.

I knew a software developer in the late 70s who wrote an in-house file archive routine. I was looking at his assembly language code, and he had a comment in there, “Will we still be using this in the year 2000? Just in case…” and he made it Y2K complaint before anyone even talked about it or it even had a name for it. Why did he do this? “Class? Because he gave a shit!”. A person with vision does things right if they are able to. Someone who developed this in 97/98 knowing about Y2K but limiting it to 2018 comes across as a poor developer. If there were other technical issues beyond their control at the time, I think it would be interesting to know them. Because history has a way of repeating itself.

[CookingWithGas]

@ftg

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.)

Please re-read my post–I have three Toyotas and none of them even have anything that displays a date. Only time.

[edwardcoast]

@CookingWithGas

Please re-read my post–I have three Toyotas and none of them even have anything that displays a date. Only time.

Here is a video of a 2000 Avalon XLS which shows time, compass direction, day of the week, month, day, outside temp and trip time. Look at around 5:42 in this Youtube video and shows other settings in this display:

Car Tour - 2000 Toyota Avalon XLS

[Hari_Seldon]

I wrote a calendar program that I still use that is correct, but only between 1901 and 2099. I don’t think I will still be using it in 81 years.

[Chronos]

Well, yes, but there’s a reason why that’s the range of applicability of your program. 1999 to 2018 just seems arbitrary.

[davidm]

@chappachula

Here’s an old but kinda relevant thread about a 2003 model Hyundai’s clock and calendar which couldn’t understand the concept of a leap year

Long, humorous,and has some detailed technical info.

One of my favorite threads!

[edwardcoast]

@Hari_Seldon

I wrote a calendar program that I still use that is correct, but only between 1901 and 2099. I don’t think I will still be using it in 81 years.

That’s your legacy? A piece of code to leave for generations to come which will stop working in 81 years? You need to re-double your efforts. Go back to that code and make it work at least out to the year 10,000. It will be one for the history books!

[edwardcoast]

@Chronos

Well, yes, but there’s a reason why that’s the range of applicability of your program. 1999 to 2018 just seems arbitrary.

It does, which is why this was a mystery to me. Could it be, someone wrote the calendar function in there correctly and then other features like in that YouTube video link I provided were added so they needed more memory to run it all? So they limited the calendar program?

[DPRK]

@edwardcoast

It does, which is why this was a mystery to me. Could it be, someone wrote the calendar function in there correctly and then other features like in that YouTube video link I provided were added so they needed more memory to run it all? So they limited the calendar program?

I don’t buy that, since calculating the day of the week is trivial.

Example (out of many):

int dayofweek(int y, int m, int d)	/* 0 = Sunday */
{
	static int t[] = {0, 3, 2, 5, 0, 3, 5, 1, 4, 6, 2, 4};
	y -= m < 3;
	return (y + y/4 - y/100 + y/400 + t[m-1] + d) % 7;
}

[chappachula]

@Hari_Seldon

I wrote a calendar program that I still use that is correct, but only between 1901 and 2099. I don’t think I will still be using it in 81 years.

YOU may not be using it in 81 years. But somebody else might.

Don’t you love your grandchildren?

[edwardcoast]

@chappachula

YOU may not be using it in 81 years. But somebody else might.

Don’t you love your grandchildren?

I’ve never see a Best Practice, which states, “If you personally have no use for this software in the future, then sling whatever crap coding scheme you wish, cause it will be someone else’s problem”.