Honda responds “We have escalated the NAVI Clock Issue to our Engineering Team and they have informed us that you will experience issue from Jan 2022 thru August 2022 and then it will auto-correct.”
You know what would have been better...? "We have made a small fix, and rerun all our build processes. Put this file on a USB drive plugged into the car and it will resolve the issue".
Or do what HP does, charge $35 for a Floppy disk instead of offering it for free download because you know, someone could use this device driver made for a specific HP model with some other hardware... /s
The issues seems to be with an old model, people talk about 2007, 2010 models etc. If they have USB ports, they'll probably be charge only, or only connected to the audio system / infotainment for iPod playback (latter might be an update path if its an infotainment system only issue). You can probably only do control unit updates over CAN (or custom methods), so unless you're a particular type of car enthusiast only a garage will have the tools.
Plus the general digital archaeology needed to get a decade old project / branch and get it and the developer tools back into a state where you can compile and test it. Probably hard to get a fix in a few days if its only just been found. That's if a non-safety critical issue on a 10+ year old car that will fix itself in 8 months is considered worthy of fixing.
In more general I suspect car companies are a bit reluctant for self-service updates like that because of the potential to brick something. If the clock problem is just tied to an infotainment display, losing that would just annoy the customer until it got to a dealer. If it for example disabled the instrument cluster, then that's a safety issue and might make the car illegal to drive (depending on local laws). If its at a dealer, a failed update can be fixed directly by the technician (replace part, or use alternative programming method etc.).
Although newer cars (particularly Tesla) are perhaps seem a bit more happy to do things like OTA updates. You really hope they don't take a "build fast and break things" approach to development. And have good self-recovery systems.
These infotainment modules do have DVD updates available, although it's unclear what code the DVDs can update (they can certainly provide a new version of the mapping application so it's evident they can replace code as well as data, but I don't know the system enough to know if they could update other functionalities). It's also unclear if the issue is too systemic to be solved by updating a single module. But, generally speaking, infotainment is already much more user-update friendly than you suggest - many infotainment modules will take (hopefully signed) updates over DVD, SD, or USB.
This is actually pretty common and for the most part the updates are signed and require user action to install. Now, of course, the signature checking is usually broken, because it's automotive stuff, but it is there :)
I kind of sympathize the engineer who had to code this in the first place years ago. I could see it, it was probably a junior person being thrown into it. He would have had to deal with non-standard components, incompatible packages and limited memory, and had a manager breathing down his neck because the manufacturing line was starting up.. He's probably looking up at the clock and thinking that it had enough bits for the foreseeable future.
I'd be a bit surprised if anyone even checked, it's easy to type int out of habit when a number is needed, or even if the dev did consider it the code building and running might be enough reassurance.
I have this problem on my 2006 Civic. I wondered if it was a GPS week rollover issue. Week numbers are 10 bits and roll over every 1024 weeks[0]. Jan 2nd, 2022 was the start of week 143 on the 2019 epoch. They may have programmed it such that "for week numbers 143-1023, assume the 1999 epoch is used; for week numbers 0-142, assume the 2019 epoch was used." Without having the clock "remember" the latest year it has seen from GPS (e.g. by writing into EEPROM), it would to be limited to 19.6 years of useful life. It's a matter of choosing which epoch they wanted to associate groups of week numbers with.
There's something more to it though, since if it was using the wrong epoch, the date would be off but the time would still be correct. Week 143 on the 1999 epoch would be May-ish 2002 but the observed behavior is that the clocks are all stuck around 4:00 on Jan 1, 2002 (and shown as a Sunday, when it was actually a Tuesday). Since the 1999 epoch started on Aug 22, 1999, I am wondering if that's another piece to the puzzle and why they suggest it will auto-correct in August.
It's an interesting problem and I'm curious about the root cause, but in reality this will just be the push I need to get a newer radio that can do CarPlay/Android Auto.
date stored as an unsigned int(32bit) is fine. It's efficient especially for smaller CE/embeded electronics. Gets us to ~2100? Hopefully most of those systems are dead by then.
You’re referring to Unix time, which is generally acceptable (if too small). The GP I think is referring to the art of storing Jan 1, 1970 8:11 as the number 197001010811 —- YYDDMMhhmm format, but as a number rather than a string. Which isn’t really that bad, since it’s ultimately the same as problem as Unix time, but it’s definitely an unnecessarily abusive encoding that’s distinctly worse than Unix time for no real gain
I have often wondered why dates are so complicated. `timespec`, `timeval`, `tm`? Why not use a 64bit unsigned int to describe the time in TAI [1] (no leap seconds, trivial computation of difference between points in time) in nanoseconds? That would give us 585 years, so our ancestors can deal with it.
Reminded me of Terry Pratchett' retroannual (?) crops, which would be ready for harvest a few years before planting, putting a lot of responsibility on the farmer not to forget to plant what he'd already eaten.
Well, if you ignore everything but "uint64_t counter go brrrr", it turns out dates and times are pretty easy.
But even a uint64_t TAI counter is incredibly underspecced. How do you handle clock drift when your local counter gets out of sync with TAI - is the counter monotonically increasing, or will time potentially replay, with all the issues that entails? What if the local clock was off by hours, days, even years? Will you clock smear if the correction is small? Within what bounds? GPS satellites will still need to correct for relativistic effects for accurate position measurement.
TAI nanoseconds since epoch will still need to be converted to and from human readable formats - doing so correctly touches on geopolitical issues (DST, timezones, leap seconds, recognized soverigenty of contested borders, etc.)
I also don't schedule relative to TAI. Suppose I schedule lunch for 1PM. What timezone? Will it track DST on reoccurences? If I move timezones, is 1PM relative to me, my device, or perhaps the device of my coworker who remains behind in the original timezone, with whom I've coordinated lunch with so we have an opportunity to chat? It turns out this is basically a natural language parsing / DWIM issue. Storing this 1PM task in TAI isn't right, even if it's not reoccuring - if I change timezones, I'm likely to be changing when my schedule is in "absolute" terms, to the degree that's even a thing, and when DST does or doesn't kick in, that also changes when my schedule is in "absolute" terms.
Dates are complicated because everything is relative. And relative to what? Well, that's suprisingly vague, even in the minds of the people using them. Between conversion bugs, ambiguous inputs, and both relativity and clock issues making any notion of absolute time an absolute farce not just in theory but in practice... dates and times end up complicated.
Is it 1:05 AM, 1:06 AM, or 1:07 AM? Depends on which clock in eyesight I'm looking at, and I'm just in my apartment.
> This thread will be locked if people cannot grow up and rein in their pseudo hysteria.
Hah, welcome to the Internet, A.D. 2022. The amount of forum posts that are either "This happened to me too!" or that plus "I can't believe it, ehat a worthless car manufacturer, I'm starting a 'Ban Honda for life'-group!!!" is way too much.
I immediately thought of boomers going off on conspiracy theories, like "this is the first step to being locked out of our cars and autonomously driving us all to the gulags. they're already being built!"
Get a grip, it's just a broken clock. God forbid a lightbulb burns out at their house.
Illegal monopolies and anti-competitive behavior[0] have that effect. Such arrangements may produce the best widget available but probably not the best widget possible. More to the point, they definitely don't produce the best possible widget for the best price.
That said, I wish Levi's still used YKK or something better than whatever no-name garbage zipper they use now in the cut I've worn for years.
If I had not known we were talking about a 2022 bug, I'd have not guessed that Y2K22 meant 2022. I'd have guessed it was using the same convention widely used in electronics for writing component values, which would give 2220.
That convention is instead of writing something like 2.2 k you write 2k2, using the scaling suffix as the decimal separator.
I don't know how this convention came about put would guess it is some combination of it being more compact which might help with legible labeling on a schematic diagram or PCB, and of it stopping bickering over whether the decimal separator should be '.' or ',' on projects with an international team.
Ah, I remember that convention from my youthful electronics-hobby days!
I always assumed that the idea was to reduce the risk of misreading due to overlooking the decimal point (or interpreting a random speck of dirt/ink/whatever as a spurious decimal point), particularly in potentially-untidy hand-drawn schematics.
But maybe I'm inventing that explanation out of nothing at all... I don't have any supporting evidence, it just seemed plausible to me.
You know, I fully understand the reasons for MS to use a date format in an integer for a version number in some kind of package; it was a bit silly of them not to use a 64-bit integer for the version number there, but at least it made sense.
With this, I don't understand the reason at all. It seems to be the same issue, but why would you ever use an integer formatted as a date to display the clock? That's the other way around, and it's probably more work to create such integers than to use string formatting!
This sucks for Honda owners because it'll take forever for any update to come out, and those updates will probably cost money as well. One of the forum users says a firmware update DVD goes for $150, that's just insane.
Not a cause. CAN messages are up to 8 bytes long, not a 64-bit signed integer. There is enough space there for packing the time as a 64-bit time_t (which will ensure it will work literally forever, as the Universe will die before it overflows) or that ugly BCD format that RTCs use (which will last for practical uses).
When I worked in the auto industry we had to fight for every bit on the CAN bus since it was always on the verge of congestion. We did insane statemachines to carry payload in unrelated bits.
I can easily see someone doing:
unsigned date = 202201011758;
*(unsigned*)&tx[0] = date;
And in another ECU:
int date = *(int*)&rx [0];
int y = date / 100000000; // -20
int M = date / 1000000 - y*100; // -93
...
Or just saturating negative numbers to 0, since integer values over 0xFD00 0000 (something) are reserved for error handling.
> With this, I don't understand the reason at all. It seems to be the same issue
> One of the forum users says a firmware update DVD goes for $150, that's just insane.
There's your answer, although some additional context: this date issue has been a repeated problem for Honda and other Japanese auto companies. They likely know, and are using it to force people to come in for service.
It's also worth noting that a large portion of Japan's economy is propped up by the auto industry, thanks to rules making it very difficult and expensive to keep a car beyond a couple years. Japan exports used cars like crazy.
Toyota in particular has almost Umbrella Corp levels of tentacles into Japanese society because they are supplied by thousands of smaller suppliers around the country. Hence their kids books explaining how hybrids are great and electric vehicles are evil...and those books actually making it in front of kids.
I have a Honda that needs that map update. That map software is some of the oldest, shittiest joystick and button driven crap ever slapped on a car. I'm talking 2005-ish vintage on a 2015 car. There's clearly a tension between hardware and that new software stuff, in their mind.
Not to mention the stupendously low amount of data available on unpredictable future medical breakthroughs that may or may not result in delaying death.
I think rather than cooking ourselves we are actually going to bring about the end of the holocene sooner than it would normally have happened. something seams to reach a tipping point at the end of each interglacial period. I like to imagine we can stop that via nuclear excavation of Panama ;-)
https://www.forbes.com/sites/paulrodgers/2014/06/30/what-sta...
It's been years since I frequented a forum like that and the admin claiming that people should just ignore it and its not an issue because people have smartphones really drives home what I hate about them.
Every time I visit a forum it really does feel like a step back in time. The inability for low quality comments to be pushed downward makes them very difficult to use.
Modern voting systems aren't perfect either, particularly in the way that they can create echo chambers/hivemind behavior, but it's a hell of a lot better than forums.
I took the time to post a possible workaround (selecting a year that mimics 2022 for calendar and leap-year status), and was promptly shut down. Apparently the moderator figured there was nothing new to discuss about the issue. Must be fun at parties, going around and shutting down individual conversations. :D
This bug impacts me. What sucks is the resale value would probably take a hit if I wanted to resell before August when the issue will supposedly disappear. Does anyone have a thought on how it will fix itself? In my head, we're already at '22' for the start of the variable value and it's only going up, so I'm not seeing how it'll fix itself intuitively.
I'm really curious how car dealers with a CR-V on the lot are handling this. I wouldn't want to buy a car the clock doesn't work on, and imagine most people wouldn't either. And with the clock resetting every time the car turns on, it's not like you can set it for the day and be fine while you run errands. I'm either stuck with this car until the automatic fix in August or until they come up with a better fix (which hopefully is free) or I need to replace the head unit to get a fair deal. Given the chip shortage and crazy price of cars, it may not be an issue for me, but it certainly is for some.
Might as well drop the Y, no one is going to confuse 2022 with anything other than the current year.
Although we risk a Honda or Microsoft engineer showing up and suggesting we drop the 20 as well and store it in the first two positions of 32-bit signed integer.
One of the comments from the linked article... things break if you write the date in this format to a 32 bit integer.
"It hasn't been in the news much but yesterday the date was written by many computers as 2201010001 (YYMMDDHHMM). Many older computers that store the date this way cannot handle any number bigger than 2147483647, so as soon as the year began with a 22, it fails and can no longer register the date/time correctly."
That's what makes it even more unfathomable how these bugs happen... Not only are they using the wrong data type, but they are using signed as well. Everytime I declare variables I think "will this ever be negative", so that I'm getting maximum value.
I drive an older Toyota car, the clock only shows hours and minutes. I wonder who decided it was necessary or helpful to start including calendar dates in a car clock display.
A lot of humans don't run on numbers and thus don't remember all the numbers that describe a certain temporal value all that well. This includes, years, months, dates, week numbers, hours, minutes, seconds, and timezone offsets.
Luckily, the devices we have around us are much better at number-things, so it was probably deemed helpful to have those devices that are (supposedly) good at numbers display them to us so when we forget, we have a reference that can help us remember.
It's on the road that I lose track of time the most. The motels all look alike, the roads look the same, and I am out of my usual routine. It's easy for me to think that it's Tuesday and not Wednesday.
Not only does my car display the date, but it has a full calendar app that reminds me of events and suggests the shortest route to get there.
The alternative would be to look at my phone while driving, which is illegal where I live. Yes, this is something that should be done outside of the car, but sometimes you need to know when you are driving and having it on the dashboard is the way to go.
> Not only does my car display the date, but it has a full calendar app that reminds me of events and suggests the shortest route to get there.
I'd rather have my phone do that, and my car (display) be a simple dumb terminal that displays whatever my phone tells it to.
I generally trust the software teams at my smartphone maker to get things more-right with these types of things: will my car maker issue patches for, e.g., DST changes?
In all honesty, I barely use the built-in OS anymore and have it to default on Android Auto. Which also display the date and calendar.
But this also has its issues. It requires a physical wire from the phone to the car and sometimes my aging phone will decide to crash/reboot during navigation.
This ended in me needing to exit the highway to reconfigure my route a few times.
Currently, my only use of the car's OS is the media center. Instead of using my phone, I have a large drive filled with music plugged in one of the USB ports.
Not only does it saves some of my phone's data and space, it makes it more stable. Using Spotify and a navigation app at the same time often has my phone freeze which can result in missing certain directions.
This is especially true when the battery reach 100% and begin heating as it tries to charge on/off.
I'd like to say it makes sense (at least in the US) so that daylight saving time transitions can be automated. My history with cars, though, is that it often is not used for that.
I drive a 2021 Toyota. When you go to the Clock setup it has an interesting feature - the first setting is for daylight saving. Turn it on, the clock goes an hour ahead, turn it off and it goes an hour back. No more fumbling with the clock twice a year, and no need to have the year. And no worrying about Congress making your clock obsolete.
Its weird, every time you start the car it goes back to Jan 1, 2002 5pm (my car is a 2010 element). The bug seems to effect cars with the gps navigation unit in the radio slot.
Attempts to override the time in settings show that the unit only allows you to "adjust existing time" by some number of hours or minutes. When you start the car, it seems to get the time from the gps again, so you can't just "fix" the time.
I used to work on systems that would work with GPS time and UTC time. Its always tricker than one would think..
I never realized how frequently I looked at the clock. If I get annoyed enough, my solution might be the stick on lcd clock.
The moderator there has shut down all conversation about this topic, so putting this possible workaround here. The mod simply responded "doesn't work", but I'd love to hear more details from someone who's experiencing the problem.
--
I have a workaround for people to try (I don't have the problem myself). I've read the related (two, I think) threads here, and haven't seen this workaround proposed, so perhaps it might work as a hack.
Others have mentioned that you can disable automatic (GPS sourced) updates, and switch to manual. If you can do that, and set the year to 1994, then your year will be wrong, but your month, day, and time will all be correct, and should suffice for the next six years, including the leap year 2024 (which would display as 1996). Unfortunately, the year 2000 is not a leap year, and you'd hit this in 2028, which is a leap year, so you'd need to set it back to 1994 again when this happens. If you can set your year back to 1966, that will give you 24 years of successful calendar updates. Other years that will work and would give you even more time would be 1938 and 1910.
There is a catch, however -- Daylight Saving Time. If the system is dumb about DST in manual mode, then everything's great, and you'll just have to adjust the clocks entering and existing DST. If it's a little bit smarter, locking in modern regimes for DST, then everything will still be great, and you won't have to adjust your clocks manually. However, if it's very smart, then US residents will have a problem, because the rules for DST changed in 2007. That means you'll have to manually adjust on the modern DST dates, and manually correct on the historical DST dates. But that's just moving updating the hours four times a year worst case. UK DST was last changed in 2002, I believe, and the same caveats apply: you may have to manually adjust your hours several times a year.
Very curious to hear if anyone has success with this hack.
95 comments
[ 3.6 ms ] story [ 170 ms ] threadhttps://www.crvownersclub.com/threads/2022-clock-fault-offic...
Plus the general digital archaeology needed to get a decade old project / branch and get it and the developer tools back into a state where you can compile and test it. Probably hard to get a fix in a few days if its only just been found. That's if a non-safety critical issue on a 10+ year old car that will fix itself in 8 months is considered worthy of fixing.
In more general I suspect car companies are a bit reluctant for self-service updates like that because of the potential to brick something. If the clock problem is just tied to an infotainment display, losing that would just annoy the customer until it got to a dealer. If it for example disabled the instrument cluster, then that's a safety issue and might make the car illegal to drive (depending on local laws). If its at a dealer, a failed update can be fixed directly by the technician (replace part, or use alternative programming method etc.).
Although newer cars (particularly Tesla) are perhaps seem a bit more happy to do things like OTA updates. You really hope they don't take a "build fast and break things" approach to development. And have good self-recovery systems.
The bad news: you can fix your car's firmware by plugging in a random USB fob.
Problem solved
There's something more to it though, since if it was using the wrong epoch, the date would be off but the time would still be correct. Week 143 on the 1999 epoch would be May-ish 2002 but the observed behavior is that the clocks are all stuck around 4:00 on Jan 1, 2002 (and shown as a Sunday, when it was actually a Tuesday). Since the 1999 epoch started on Aug 22, 1999, I am wondering if that's another piece to the puzzle and why they suggest it will auto-correct in August.
It's an interesting problem and I'm curious about the root cause, but in reality this will just be the push I need to get a newer radio that can do CarPlay/Android Auto.
[0] https://en.wikipedia.org/wiki/GPS_week_number_rollover
And here I thought something this blatantly stupid was just an urban myth among programmers. Huh.
https://www.computerworld.com/article/2529992/zune-chokes-on...
And the ever looming 32bit problem https://en.wikipedia.org/wiki/Year_2038_problem
date stored as an unsigned int(32bit) is fine. It's efficient especially for smaller CE/embeded electronics. Gets us to ~2100? Hopefully most of those systems are dead by then.
[1] https://en.wikipedia.org/wiki/International_Atomic_Time
What kind of clock is this!?
https://wiki.lspace.org/Hangunder
But even a uint64_t TAI counter is incredibly underspecced. How do you handle clock drift when your local counter gets out of sync with TAI - is the counter monotonically increasing, or will time potentially replay, with all the issues that entails? What if the local clock was off by hours, days, even years? Will you clock smear if the correction is small? Within what bounds? GPS satellites will still need to correct for relativistic effects for accurate position measurement.
TAI nanoseconds since epoch will still need to be converted to and from human readable formats - doing so correctly touches on geopolitical issues (DST, timezones, leap seconds, recognized soverigenty of contested borders, etc.)
I also don't schedule relative to TAI. Suppose I schedule lunch for 1PM. What timezone? Will it track DST on reoccurences? If I move timezones, is 1PM relative to me, my device, or perhaps the device of my coworker who remains behind in the original timezone, with whom I've coordinated lunch with so we have an opportunity to chat? It turns out this is basically a natural language parsing / DWIM issue. Storing this 1PM task in TAI isn't right, even if it's not reoccuring - if I change timezones, I'm likely to be changing when my schedule is in "absolute" terms, to the degree that's even a thing, and when DST does or doesn't kick in, that also changes when my schedule is in "absolute" terms.
Dates are complicated because everything is relative. And relative to what? Well, that's suprisingly vague, even in the minds of the people using them. Between conversion bugs, ambiguous inputs, and both relativity and clock issues making any notion of absolute time an absolute farce not just in theory but in practice... dates and times end up complicated.
Is it 1:05 AM, 1:06 AM, or 1:07 AM? Depends on which clock in eyesight I'm looking at, and I'm just in my apartment.
Hah, welcome to the Internet, A.D. 2022. The amount of forum posts that are either "This happened to me too!" or that plus "I can't believe it, ehat a worthless car manufacturer, I'm starting a 'Ban Honda for life'-group!!!" is way too much.
Eternal September called and wants its complaints back
Get a grip, it's just a broken clock. God forbid a lightbulb burns out at their house.
https://slate.com/business/2012/04/ykk-zippers-why-so-many-d...
That said, I wish Levi's still used YKK or something better than whatever no-name garbage zipper they use now in the cut I've worn for years.
[0]https://www.reuters.com/article/idUSL1926941520070919
https://www.ykkfastening.com/brand/counterfeit.html
I guess the obvious answer is that everyone knows "Y2K" so "Y2K22" communicates more clearly what it is about.
That convention is instead of writing something like 2.2 k you write 2k2, using the scaling suffix as the decimal separator.
I don't know how this convention came about put would guess it is some combination of it being more compact which might help with legible labeling on a schematic diagram or PCB, and of it stopping bickering over whether the decimal separator should be '.' or ',' on projects with an international team.
I always assumed that the idea was to reduce the risk of misreading due to overlooking the decimal point (or interpreting a random speck of dirt/ink/whatever as a spurious decimal point), particularly in potentially-untidy hand-drawn schematics.
But maybe I'm inventing that explanation out of nothing at all... I don't have any supporting evidence, it just seemed plausible to me.
With this, I don't understand the reason at all. It seems to be the same issue, but why would you ever use an integer formatted as a date to display the clock? That's the other way around, and it's probably more work to create such integers than to use string formatting!
This sucks for Honda owners because it'll take forever for any update to come out, and those updates will probably cost money as well. One of the forum users says a firmware update DVD goes for $150, that's just insane.
Maybe the master date is sent over CAN and the bug is in the sender?
I can easily see someone doing:
And in another ECU: Or just saturating negative numbers to 0, since integer values over 0xFD00 0000 (something) are reserved for error handling.Maybe they have a "Y since X", hit the Autosar reserved range at 0xfd..., and it wraps around 0xff... to 0 in August?
A free running counter through the "non physical" range is the only thing I could think of that would behave like this and fix it self by a date.
The timer could be any bit width or unit really.
> One of the forum users says a firmware update DVD goes for $150, that's just insane.
There's your answer, although some additional context: this date issue has been a repeated problem for Honda and other Japanese auto companies. They likely know, and are using it to force people to come in for service.
It's also worth noting that a large portion of Japan's economy is propped up by the auto industry, thanks to rules making it very difficult and expensive to keep a car beyond a couple years. Japan exports used cars like crazy.
Toyota in particular has almost Umbrella Corp levels of tentacles into Japanese society because they are supplied by thousands of smaller suppliers around the country. Hence their kids books explaining how hybrids are great and electric vehicles are evil...and those books actually making it in front of kids.
Have you got a link to any photos of those? I can't find them
https://electrek.co/2021/11/11/how-toyota-sneakily-spreads-a...
Really more informational pamphlets than kids books.
Yes it’s overpriced, but it’s not $150 for a firmware update and nothing else.
I appreciate the optimism regarding the long-term survival of the human race.
Whether that chance is greater than the chance of the human race lasting another 8000 years; I'm not sure.
I think rather than cooking ourselves we are actually going to bring about the end of the holocene sooner than it would normally have happened. something seams to reach a tipping point at the end of each interglacial period. I like to imagine we can stop that via nuclear excavation of Panama ;-) https://www.forbes.com/sites/paulrodgers/2014/06/30/what-sta...
Modern voting systems aren't perfect either, particularly in the way that they can create echo chambers/hivemind behavior, but it's a hell of a lot better than forums.
I'm really curious how car dealers with a CR-V on the lot are handling this. I wouldn't want to buy a car the clock doesn't work on, and imagine most people wouldn't either. And with the clock resetting every time the car turns on, it's not like you can set it for the day and be fine while you run errands. I'm either stuck with this car until the automatic fix in August or until they come up with a better fix (which hopefully is free) or I need to replace the head unit to get a fair deal. Given the chip shortage and crazy price of cars, it may not be an issue for me, but it certainly is for some.
Although we risk a Honda or Microsoft engineer showing up and suggesting we drop the 20 as well and store it in the first two positions of 32-bit signed integer.
But I am not following what about "2022" could have caused something like this in a few different areas. Can someone explain?
"It hasn't been in the news much but yesterday the date was written by many computers as 2201010001 (YYMMDDHHMM). Many older computers that store the date this way cannot handle any number bigger than 2147483647, so as soon as the year began with a 22, it fails and can no longer register the date/time correctly."
If this was using unsigned it would work until 2042.
Luckily, the devices we have around us are much better at number-things, so it was probably deemed helpful to have those devices that are (supposedly) good at numbers display them to us so when we forget, we have a reference that can help us remember.
Not only does my car display the date, but it has a full calendar app that reminds me of events and suggests the shortest route to get there.
The alternative would be to look at my phone while driving, which is illegal where I live. Yes, this is something that should be done outside of the car, but sometimes you need to know when you are driving and having it on the dashboard is the way to go.
I'd rather have my phone do that, and my car (display) be a simple dumb terminal that displays whatever my phone tells it to.
I generally trust the software teams at my smartphone maker to get things more-right with these types of things: will my car maker issue patches for, e.g., DST changes?
But this also has its issues. It requires a physical wire from the phone to the car and sometimes my aging phone will decide to crash/reboot during navigation.
This ended in me needing to exit the highway to reconfigure my route a few times.
Currently, my only use of the car's OS is the media center. Instead of using my phone, I have a large drive filled with music plugged in one of the USB ports.
Not only does it saves some of my phone's data and space, it makes it more stable. Using Spotify and a navigation app at the same time often has my phone freeze which can result in missing certain directions.
This is especially true when the battery reach 100% and begin heating as it tries to charge on/off.
Its weird, every time you start the car it goes back to Jan 1, 2002 5pm (my car is a 2010 element). The bug seems to effect cars with the gps navigation unit in the radio slot.
Attempts to override the time in settings show that the unit only allows you to "adjust existing time" by some number of hours or minutes. When you start the car, it seems to get the time from the gps again, so you can't just "fix" the time.
I used to work on systems that would work with GPS time and UTC time. Its always tricker than one would think..
I never realized how frequently I looked at the clock. If I get annoyed enough, my solution might be the stick on lcd clock.
https://www.amazon.com/Bell-Automotive-37003-Stick-Clock-Bla...
https://en.m.wikipedia.org/wiki/GPS_week_number_rollover
"Software that is not coded to anticipate the rollover to zero may stop working or could be moved back in time by 20 or 40 years"
I have a workaround for people to try (I don't have the problem myself). I've read the related (two, I think) threads here, and haven't seen this workaround proposed, so perhaps it might work as a hack.
Others have mentioned that you can disable automatic (GPS sourced) updates, and switch to manual. If you can do that, and set the year to 1994, then your year will be wrong, but your month, day, and time will all be correct, and should suffice for the next six years, including the leap year 2024 (which would display as 1996). Unfortunately, the year 2000 is not a leap year, and you'd hit this in 2028, which is a leap year, so you'd need to set it back to 1994 again when this happens. If you can set your year back to 1966, that will give you 24 years of successful calendar updates. Other years that will work and would give you even more time would be 1938 and 1910.
There is a catch, however -- Daylight Saving Time. If the system is dumb about DST in manual mode, then everything's great, and you'll just have to adjust the clocks entering and existing DST. If it's a little bit smarter, locking in modern regimes for DST, then everything will still be great, and you won't have to adjust your clocks manually. However, if it's very smart, then US residents will have a problem, because the rules for DST changed in 2007. That means you'll have to manually adjust on the modern DST dates, and manually correct on the historical DST dates. But that's just moving updating the hours four times a year worst case. UK DST was last changed in 2002, I believe, and the same caveats apply: you may have to manually adjust your hours several times a year.
Very curious to hear if anyone has success with this hack.