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.
> 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.
Yes it’s overpriced, but it’s not $150 for a firmware update and nothing else.
Have you got a link to any photos of those? I can't find them
Maybe the master date is sent over CAN and the bug is in the sender?
I appreciate the optimism regarding the long-term survival of the human race.
https://www.crvownersclub.com/threads/2022-clock-fault-offic...
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.
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.
https://slate.com/business/2012/04/ykk-zippers-why-so-many-d...
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.
I guess the obvious answer is that everyone knows "Y2K" so "Y2K22" communicates more clearly what it is about.
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.
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.
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 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.
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.
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.
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.
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.
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...
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.
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"
