I own three vehicles. The newest one was built in 2008. They’re all dumb vehicles. They have gauges on the dashboard and the only “screen” any of them have are primitive segmented LED displays on their radios. The clocks only know how to display hours and minutes and need to be manually set whenever daylight savings time changes (or the battery is disconnected).
To me a vehicle is a long term purchase. When I buy one, I assume that I’ll be driving it until is stops functioning. I want at least a decade and always hope for more. Because I tend to drive vehicles for a long time, I avoid vehicles that have built-in navigation, touch screens, or infotainment systems. Vehicle manufacturers are notoriously bad at software. Not only do they tend to write software poorly, they also don’t provide updates for very long. That can lead to awkward situations like your clock rolling back 1024 weeks:
The Jalopnik inbox has been lit up with a number of reports about clocks and calendars in Honda cars getting stuck at a certain time in the year 2002. The spread is impressive, impacting Honda and Acura models as old as 2004 and as new as 2012. Here’s what might be happening.
If you scroll through a Honda or Acura forum right now, chances are you’re going to run into a bunch of confused owners. When they hopped into their cars on January 1 they found the clocks on their navigation systems frozen at a certain time. And the calendar date? 2002, or 20 years ago.
[…]
Drive Accord forum user Jacalar went into the navigation system’s diagnostic menu on Sunday and discovered that the GPS date was set to May 19, 2002, or exactly 1024 weeks in the past.
Global Positioning Systems measure time from an epoch, or a specific starting point used to calculate time. The date is broadcasted including a number representing the week, coded in 10 binary digits. These digits count from 0 to 1023 then roll over on week 1024. GPS weeks first started on January 6, 1980 before first zeroing out on midnight August 21, 1999. It happened again April 6, 2019. The next happens in 2038.
Synchronizing time with GPS is an intelligent choice. But you have to understand the specification. Since the week counter for GPS rolls over every 1024 weeks, you need your system to take that into account and adjust accordingly. Honda didn’t take that into consideration so now the clock on a bunch of their vehicles is stuck 20 years in the past. Making the matter worse is that Honda hasn’t provided a fix and, if history is any indicator, may never provide a fix (or at least not provide a fix for vehicles past a certain manufacturing date).
This problem is just another on the long list of what I like to call software based obsolescence. Software based obsolescence isn’t necessarily planned obsolescence. I doubt anybody at Honda implemented a plan to cause this issue. In all likelihood the software developers were ignorant of the fact that the GPS week counter rolls over every 1024 weeks. Because they were ignorant of that behavior, the didn’t take it into consideration when they wrote the software (in fact the developers may have been using a third-party library for syncing time with GPS and that library didn’t take the rollover into consideration).
As a general rule software doesn’t age well. The more complex a piece of software is, the worse it will age (obviously exceptions to the rule exist). So software written to control a specific process in your engine may age fine, but software that handles time synchronization (a surprisingly complex task) will likely age poorly. This is why software patches exist. However, when you combine increasingly complex software with systems that cannot be updated or will not be updated after a specific period of time, that product, if it’s dependent on software, will have the same life expectancy as the software. In the case of the Honda vehicles mentioned in the story, the rest of the vehicle is able to operate properly even if the time synchronization is broken. But if a system depends on an accurate clock, then improper time synchronization will break that system.
This is why I prefer to avoid systems that are reliant on software unless I only plan to use the platform for a specific period of time or the platform is open to user modification and the software it depends on is open source.