Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading!

 


Forgot your password?
Close
typodupeerror
×
Transportation Bug

Honda Clocks Are Stuck 20 Years In The Past And There Isn't A Fix (jalopnik.com) 117

Posted by BeauHD from the what's-going-on dept.
Honda and Acura owners around the world are reporting that their clocks and calendars are 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," reports Jalopnik. "There is no fix for the current issue. Honda says it's investigating and if it does not find a fix, the clocks should correct themselves sometime in August." From the report: As a number of Honda and Acura owners have noted on these forums, their clocks read correctly until what appeared to have been the first time update of 2022. Then, their navigation systems turned into time machines, leaving them behind as they went back to 2002. I asked Honda about the cause of the issue and received this back: "American Honda is aware of a potential concern related to the clock display on certain older Acura and Honda models equipped with navigation systems. We are currently investigating this issue to determine possible countermeasures and have no additional details to share at this time." Owners have also reached out and received different responses.

If you have experience coding or troubleshooting software, the possible cause of this time warp probably popped into your head early on. 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.

If software isn't coded to account for the rollover, weird stuff can happen, like a calendar going back exactly 1024 weeks. It's impossible to know for sure without being able to look at Honda's programming, but these navigation systems might be programmed so that the start of their week counter is a date 19.6 years in the past, but not in-line with GPS epoch. Owners should be able to turn off the automatic update function and set the date and time manually, but they're finding that the functionality doesn't work right now. Likewise, the clock resets back to the incorrect time every time the car is started.
This discussion has been archived. No new comments can be posted.

Honda Clocks Are Stuck 20 Years In The Past And There Isn't A Fix More

Honda Clocks Are Stuck 20 Years In The Past And There Isn't A Fix

Comments Filter:
  • Sounds like some Honda owners will enjoy their cars for longer, given that the time-bomb mechanisms now will trigger later than planned for!

  • Going downhill (Score:1)

    by Anonymous Coward
    The 1988 Honda clock prevented display of incorrect settings (and correct ones) by emitting smoke and no longer displaying anything (vacuum fluorescent).

  • Oh, is that all? (Score:3)

    by quonset ( 4839537 ) on Thursday January 06, 2022 @06:49PM (#62150415)

    their clocks read correctly until what appeared to have been the first time update of 2022.

    In other words programmers screwed things up again. But yeah, let's keep offering more money to hire them.

    • Re:Oh, is that all? (Score:5, Funny)

      by thegarbz ( 1787294 ) on Thursday January 06, 2022 @07:30PM (#62150535)

      But yeah, let's keep offering more money to hire them.

      Have you ever tried hiring programmers without offering them money? Screwed up dates will be the least of your problems.

      • Re: (Score:2)

        by PPH ( 736903 )

        Have you ever tried hiring programmers without offering them money?

        We just need a better way to select the proper ones to offer the money.

        • Re: Oh, is that all? (Score:3, Insightful)

          by too2late ( 958532 )
          There needs to be licensure for programmers. Hair dressers have to be licensed to cut hair in the US but programmers can write software that can literally kill people if not written correctly with little or no proof they actually know how to code.

          • Yup. If you are a professional electrician then it's likely you have read the relevant building codes, understand the national standards, and actually understand some things about electricity. But for a professional programmer so many of them I see seem to have learned from "How to Program in In 20 Days" with the bookmark still stuck on day 6. These days probably most of them learned by watching some youtube videos. It boggles my mind that someone whose profession is to write code usually has never onc

          • Hair dressers are licensed, and they still fuck up. Doctors are licensed, and they still fuck up. Electricians are licensed, and they still fuck up. Even if you license programmers, you'll encounter some fuck ups.

            • Murder is illegal yet there is still some murder. I guess the law isn't necessary at all!

            • You miss the point. Its about accountability and a client being able to put a certain level of trust in a licensed professional. You may be a wonderful engineer, but your client is not an engineer and they have no way to know that. A licensed engineer has the authority of a professional union behind them that vetted them and their abilities.

              Furthermore, if the quality of the work causes monetary or physical harm to the client, then the engineer can clearly be held liable. Without a professional certificatio

        • We clearly need to have higher-paid managers to select the proper programmers.

      • I wish a lot of contracts came with clause stipulating that they will clean up their own shit for free instead of demanding to be paid for the privilege. I swear one guy I worked with that we no longer pay seemed to have the most bizarre untested/unreviewed code just so that we would have to keep paying him to fix it when it broke. And yet so many past and present managers seem to think he walks on water because he gets stuff done, while not noticing that the stuff doesn't actually work, and that the reas

        • Re: (Score:3)

          by swilver ( 617741 )

          Then also please put a complete specification in the contract of what should be delivered.

          • Naw, many of these contractors are really just employees. At some point someone told them that they should be indepdendent contractors with their own one-person company, and they did that. I don't think a contract actually exists to be honest beyond "you report to manager X and do the job assignments given to you." This guy is one of those, started as a startup employee and later became a contractor.

            On the other hand, someone in a test team, very junior as I think it was his first job, did the same thing

          • Re: (Score:3)

            by jythie ( 914043 )
            Heh. I remember the day of 400 page detailed user specifications being written before a single line of code was started. I am not sure I would want to go back to that, and I imagine younger programmers who learned newer norms would explode.

    • This is the 20 year rollover in GPS. Programmers possibly screwed up 19 years ago. It's a lot of thinking that if things work today then they'll work tomorrow also. Why plan ahead when we can patch it later? Or the thinking that "we'll upgrade everything before this happens." And the fix is simple - if the date from GPS is less than the date of the firmware was compiled, then add 1024 weeks until it isn't. As long as there's a firmware update more often than once every 20 years it works just fine. It's

      • Re: (Score:2)

        by narcc ( 412956 )

        I'm dealing with that attitude while working on an archaic code base where in 2005 they couldn't be bothered to use the C1999 standard,

        That doesn't seem unreasonable to me. Compiler support for C99 is still spotty more than 20 years later, after all. I still write a lot of code to C89.

        • A prominent storage (hardware) company was using K&R C (pre-C89, who needs function prototypes?) for their firmware as recently as four years ago. Might still be using it, but my contact left for greener pastures. It was fun to tease my buddy and tell him he was using a C standard that was older than he was.

      • Re: (Score:3)

        by edwdig ( 47888 )

        It's also possible that they were aware of the bug, but just didn't care. It's an optional feature not included in most models. The vast majority of cars have a useful life of about 10 years, give or take a few. If they were coding this for the 2004 model cars, there's a good chance someone was aware of it but decided that it wasn't worth the effort to fix it. Based on the year range listed, they didn't bother fixing this until about when you reached the point that you would expect most cars to run into the

        • This was gcc, and the compiler they first used I was positive had c99 support. But they were all self taught to the minimum amount possible (EE people) and none were experts. So I kind of inherited it now that i'm senior and trying to drag things kicking and screaming into the modern age.

    • GPS rollover was in 2019.
      Problem is that many OEMs use a separate epoch, which is the wrong way to do it, especially in a car that has a long liftime !
      Correct way to do is to detect the rollover, and maintain "enough" extra bits to the week counter in a NV storage.

    • Re:Oh, is that all? (Score:4, Funny)

      by AmiMoJo ( 196126 ) on Friday January 07, 2022 @04:57AM (#62151389) Homepage Journal

      Having written several clock systems in my career I've got into the habit of fully testing them, i.e. stepping them through every possible value up to the known overflow point. I also do that for any function that converts time, e.g. seconds since epoch to Gregorian date.

      Usually I write a little shell program that used the clock code to output times sequentially, and then a C# program that uses the .NET DateTime stuff to check each line of the output. Pipe them together and look for errors. I've found the .NET code to be reliable, and figured if it did have bugs then my own code is unlikely to have the exact same flaw.

  • The Matrix is Real! (Score:1)

    by Anonymous Coward
    This is proof that the Matrix is real. Everything after 2002 is all a fabrication.

  • This Has Happened Before (Score:3)

    by WankerWeasel ( 875277 ) on Thursday January 06, 2022 @07:01PM (#62150443)
    Had this happen before. Had it happen some years ago on my Acura. It's a problem with the Pioneer-made navigation system. Took them 6+ months to remedy it. They eventually sent out new discs to everyone. Everyone got a free upgrade (normally they charged $99 for new maps every year). You couldn't change the time on the navigation systems.
    • I would like to act superior by saying "That's why I don't buy the model with the built-in NAV function", but sadly, my Honda had a clock failure without having the NAV. I bought a new 2012 Civic, and the clock ran so fast that it was gaining several minutes a day. It was probably a simple calibration that was missed, but it took weeks to get a new replacement part ordered. When the dealer finally installed it, it took 4 Hours (because it was a new model, the tech had no experience with it), and now, when t
      • The Pioneer touchscreen stereo I put in my Acura runs fast. After a month it's a minute or two faster than the clock on my nav system and my Apple Watch (and it's pretty hard to get more accurate than that). Really bothers me that I have to remove a minute or two here and there. It's not that hard to calibrate a freakin' crystal.

      • You of course realize the do this on purpose so they can bill you for having to go to the dealer. Their dealers would really lose out if you could just pop in a USB, SD, etc to do the update.

      • There are a lot of products that use GPS solely for getting time.

    • Re: (Score:2)

      by caseih ( 160668 )

      No. Your wikipedia link states that the last week rollover event occurred in 2019, and no one had any issues until very recently. In fact their date read 2022 until a recent time update flipped them to 2002.

      • year 2022 - 20 years is GPS Rollver.

        • Re: (Score:2)

          by caseih ( 160668 )

          How do you figure? Did you read the article you linked to? It says there was one in 1999 and another in 2019. Nothing about anything in 2022.

          • Re: (Score:2)

            by mce ( 509 )
            Go read my other posts on this topic that explain why there can be delays in the symptoms showing up. As I've written: I've seen this very kind of bug before, including such delays. I actually worked on the system in question for many years (though not at the guilty party).

      • The rollover date depends upon the device. They are not all synchronized. Otherwise, those who made a new product in 2018 would have seen the failure after only 1 year in the field. What they often do is assume a basic starting date that's added to the GPS time, so that the product will have a 19.6 year lifetime before things break. Ie, like using a different epoch date/time.

        Ie, part of what you get from GPS is a week number from 0 to 1023. If you build a device in week 512, then the firmware can just

        • Exactly correct. Itâ(TM)s the GPS rollover + a manufacturer specific offset.

          There was some concern a few years ago when some GPS-disciplined oscillators used as time and frequency standards in common use among the âoetime nutâ community were coming up on their specific rollover. The devices were obsolete and no new firmware was available, but the community updated the various software that processes data from the devices in time and all was well.

          It seems things were handled less well by Honda

    • Nice link. And it links to this, which is ... awesome? Sad? Another brick in my misanthropic wall? https://en.m.wikipedia.org/wik... [wikipedia.org]

  • Here's what's happening (99% sure) (Score:5, Interesting)

    by mce ( 509 ) on Thursday January 06, 2022 @07:19PM (#62150493) Homepage Journal

    ... these navigation systems might be programmed so that the start of their week counter is a date 19.6 years in the past, but not in-line with GPS epoch.

    This is exactly what is going on. I've seen this before with a german OEM, but they were aware (the bug was was not their own software, by the way) and they fixed it ahead of time through FOTA updates - and likely also some dealership updates in case FOTA failed for some reason or in case a car happened to be at a dealer anyway for maintenance. That was when the 2019 rollover was coming up and the system in question was certain to fail about 6 months later.

    What happened was really silly. When the software in question was written, the programers knew that the 1024 weeks were a potential issue. So one would expect them to implement a correct and failsafe solution for it (it's easy enough to do: monitor the week counter and if you see it wrap around just apply the correct offset solution). Instead, their braindead idea was to postpone the problematic date by shifting all caclulations by the number of weeks of the then current cycle that had already passed. And then just hope that this would be enough... What could ever go wrong?

    • Re:Here's what's happening (99% sure) (Score:4, Insightful)

      by timeOday ( 582209 ) on Thursday January 06, 2022 @07:35PM (#62150555)
      I won't defend their mistake, but implementing date/time functions correctly is actually hellishly difficult. Nobody should ever do it. You start out thinking it's just a counter with some modulus operations... except this.. and that.. and leap-seconds... it never ends.

      • Re: (Score:2)

        by mce ( 509 )

        Except that there is no easy standard library function for converting a GPS signal into a date - in part because of this epoch issue, since you always need to specify the most recent reference date to base the calculations on and the fact that this date is changing is the main issue you have to deal with. Tracking the reference date bit is something you have to yourself anyway.

        I agree that this is difficult (e.g. not only do you need to monitor the counter for wrap around over time, but you must also bein

        • Re: (Score:2)

          by mce ( 509 )

          (Replying to myself.)

          While writing another post on this topic, I remembered something more: In the case of the German OEM's supplier, the bug had been in the code for very long - probably even from before the 1999 rollover. At some point, the maintainers apparently got a bit worried about their trick and made it so that their own reference date was updated based on the compilation date of their software. Except that they did not update the date at each release, but only every so many years. We actually f

        • Re:Here's what's happening (99% sure) (Score:4, Interesting)

          by Darinbob ( 1142669 ) on Thursday January 06, 2022 @09:48PM (#62150877)

          If the firmware/library gets updated any time during those 20 years then it could also change the epoch date at the same time. As long as you get periodic update it could last forever. That because the context for which GPS time is used is always for the current time of "now". You don't have to worry about the problems of trying to wedge the 32-bit Unix time to work for the original use of file dates as well as birth dates and historical events in the past, etc. So if you know that you're in the year 2022 today, that there's no way that the time you get from the GPS is for 2002, so just add 19.6 years to it.

          This can work for 32-bit Unix time as well, and I've seen code that just updates the Epoch date by a fixed amount.

          Figuring out time is hard, but it's not as hard as some think it is. The bigger problem is from developers who learned how to tell time in kindergarten and therefore think that they're now experts in the concept of time. I remember explaining the same thing several times to one developer until it finally clicked. The issue there was with a particular device that insisted every day would have 24 readings logged per hour, every day, regardless of daylight savings time, never 23 or 25; so when the time change came around they would either drop one reading or duplicate one. It was crazy, but I honestly thnk they did it that way so that the customers would not be confused and file bug reports and refuse to believe that some days actually have 25 hours in them.

          • Re: (Score:2)

            by mce ( 509 )

            As I mentioned in another comment: You can't assume that the FW will be upgraded frequently, or at all for that matter.

            Actually, this assumption was part of the problem for the system that I worked on. The company that produced the bug was in the cellular communications business, which so many years ago meant that no product that would use their chip (at that time only phones) would survive for 20 years, and if few one did so anyway, well who cares... They knew full well that many of those devices would

            • As I mentioned in another comment: You can't assume that the FW will be upgraded frequently, or at all for that matter.

              Cars can last for decades, if the manufacturer continues to exist they should have to fix bugs like this. And they should build processes and systems to permit them to do that even much later without it being horrendously expensive. Or, you know, they can have it be expensive if they want, but that would be dumb.

              • Re: (Score:2)

                by mce ( 509 )

                Car manufacturers do all that. This is one reason why automotive grade components cost much more then similar consumer grade ones: car manufacturers demand long-time support and/for long lifetimes. It is also why some component companies flat out refuse to sell non-automotive components to someone working in the automotive industry, even when you tell them that your intended use is not for in-car application. They just don't want to take the risk.

                All of that is how we managed to fix our 2019 problem back

                • Car manufacturers do all that.

                  Eh, sometimes, and kinda.

                  • Re: (Score:2)

                    by mce ( 509 )

                    I know... :-(

                    14 years in that industry have told me that I don't want to buy a car from any of the very major brands I've been supplying to, because I know to much. But then again, all others are likely the same.

    • Re: (Score:2)

      by AmiMoJo ( 196126 )

      I've seen this happen, the bug being in the firmware of the GPS module. The GPS module outputs the current date and time in ddmmyy and sometimes other formats, but internally it has to calculate it using the GPS week value that is only 10 bits (overflows at 1024).

      There are two possible fixes, either update the firmware of the GPS module or update the software in whatever is listening to it. Chances are the manufacturer has long since lost interest in updating firmware for an old GPS module.

      It's a tricky one

      • Re: (Score:3)

        by mce ( 509 )

        Indeed.

        In our case, the GPS manufacturer had long since moved on to newer devices. They did still provide fixes for the old ones (a must in the automotive industry), but only when they really had no other way out. In fact, we used multiple generations of their products at the same time and when we found out about this problem in one of the devices, we discovered that they had updated the reference date for their "let's offset the week counter" trick in newer devices, but had not released similar updates fo

  • Twenty years ago, practically everything was better.

  • Just curious, but what does this break? Do the bars do something where the date matters? (I drive a cheap, old car with a 12 hr clock; my car doesn't even understand the difference between 8 am and 8 pm, much less 2002 vs 2022.)
    • Wrote bars, meant cars. Must be drinkin' time.

    • Re: (Score:2)

      by jrumney ( 197329 )
      It will break anything using TLS/SSL, as certificates will all be outside their validity period. And things like the day of week matching the actual day, and Feb 29 being used in the right years can also be broken if clock offsets are not matching perfectly.

    • It's not just the year. The rollover period is 1024 weeks, which is around 19.6 years. So the month and day will also change with this bug which is a lot more disconcerting to the customer (omg, it's monday already?!)

  • Real flaw is you can't manually set the clock (Score:5, Insightful)

    by mdpowell ( 256664 ) on Thursday January 06, 2022 @07:40PM (#62150573)

    The real negligence here is that there is no way to manually and persistently set the clock and turn off auto updates. This embarrassment should be used as a case study in programming classes.

    I have one of these Hondas, and if I use the awkward clock adjust mechanism, the adjustment doesn't survive the next key-off key-on cycle.

    Regarding the GPS rollover issue, it continues to amaze me that so many GPS units don't use a few bits of non-volatile memory to make sure time never runs "backwards." A nibble worth would provide a few centuries of correct date and time as long as the unit is turned on at least once every ~19 years.

    • The time comes to implement code to deal with time, and the manager asks the team "who here understand how time works?" Everyone raises their hand. "Great, I'll just assign this relatively minor task to the new guy then!"

      • Where's the merge request where that junior's code is reviewed by a more experienced peer?

        • Sadly, we didn't have that in a rigorous way. And it was often the experienced peer who had the worst code (ie, senior because they worked there the longest, and their expertise was in the application or engineering and not in the coding.

          For example, originally code was committed first and then reviewed. And it was often reviewed at the last minute. So if you had a minot quibble with the code you would get pushback that it was a lot of effort for something minor and would delay the release. If you had a

          • Re: (Score:2)

            by Malc ( 1751 )

            Yeah, the tools these days certainly make it a lot easier to implement good processes. Changing attitudes and mindsets that are long engrained is often the biggest challenge, as is getting people to change their highly optimised way of working at a short-term cost to their personal efficiency. If you can pull it off with the toolset change, with time, many people seem to come around.

    • Re: (Score:2)

      by Megane ( 129182 )

      Sony once made an antenna DVR which automatically set its clock based on a sub-signal in a service on some TV channels. This was mostly only on PBS stations, and IIRC it may have only been in the analog signal. There was no other way to set the clock on the unit. Once the service went away, that DVR became as useful as a brick.

      Allowing the user to enter the date (or at least the year) manually could be used as a hint for the GPS epoch, but that would probably require support inside the GPS module itself. A

  • Man, I can just picture some guy compelled to reprogram the clock twice a day for their commute. What a nightmare.
  • The clock of my Honda Civic is just goes round every 12 hours. It does not take years into account. What is this nonsense? Why would a car clock monitor the year?
  • The only way that I can set the clock in my 2004 Acura TSX is to disconnect the battery, and then reconnect it at exactly 1:00 PM. Thankfully, the GPS still works properly. Still love the car, though! Manual transmissions are a dying breed.

  • The fix is to use your smartphone (Score:3)

    by presidenteloco ( 659168 ) on Thursday January 06, 2022 @08:31PM (#62150709)
    for navigation. Works well on my 1997 pre-GPS-equipped vehicle.

  • "the clocks should correct themselves sometime in August."

    That's funny. How will we know when it's August? I thought I bought a car, not a defective calendar, dammit!

    I've made some bad choices in writing software before but fortunately nothing worthy of making /.

  • Computer timekeeping systems never measure time in weeks. Usually, date/time values are stored as a floating point number, or in hardware, as a number of "ticks," often 65,535 ticks per second, since some start date/time. In either case, the number of weeks is always calculated from that number. No timekeeping system I know of, starts with weeks and subdivides them. I'm not buying the 1024 weeks theory, though I do buy the general "rollover" bug theory.

    • Comment removed based on user account deletion

    • Usually, date/time values are stored as a floating point number

      Where would you find that and how does that representation work?

      • Re:1024 weeks? Really? (Score:4, Informative)

        by Tony Isaac ( 1301187 ) on Friday January 07, 2022 @08:06AM (#62151637) Homepage

        MS Excel / Open Office Calc, and SQL Server are systems (among others) that store date/time values as a floating point number of days since December 31, 1899. So noon on January 1, 1900, is represented as the floating-point number 1.5. To see this, open Excel and type the date 1/1/1900 in A1. In A2, type the formula =A1+1. It will show 1/2/2900. Now, change the column format of Column A to "Number." This will show you the floating-point numbers behind the dates. To see the time portion, try =A1+1.5 and format the cell as "Time."

      • Re: (Score:2)

        by Megane ( 129182 )
        I think NeXTStep/OS X uses a double-float representation of microseconds in the Unix epoch. You have to go way into the future before you start losing bits of mantissa (52 bits!), and way way into the future before it starts affecting seconds.

    • Computer timekeeping systems never measure time in weeks. [...] I'm not buying the 1024 weeks theory, though I do buy the general "rollover" bug theory.

      Overconfident Slashdot poster, meet GPS week numbers [wikipedia.org].

      • LOL

        The article contradicts itself. It says the rollover occurs every 19.6 year, but then lists 2019 and 2022 (Honda) as rollover years. Those can't both be true.

        • LOL

          The article contradicts itself. It says the rollover occurs every 19.6 year, but then lists 2019 and 2022 (Honda) as rollover years. Those can't both be true.

          *sigh*, yeah, there can be offsets involved in actual implementations. The article could be clearer about that. It probably will be in a while.

          Also: Primary source [navy.mil]. So, RTFM and go away.

  • I just use a watch.

    • Further, don't use in-car GPS. I've never actually used in-car GPS, anyway. I've been driving for over 40 years and none of my vehicles have had it. If I use a rental car, I ignore it. Push comes to shove and I don't know my way around, I have either an iPad or an iPhone and they'll get me where I need to go.

      This feels like it needs a "Get off my lawn!"

  • Mine just doesn't keep good time, always runs fast.
    Evidently Honda didn't talk to Timex.

  • As much as I sometimes loathe Tesla's OTA firmware updates which every year will change the UI just because they want to, I'm also glad that fixing such bugs is only a OTA firmware update away.

    • Comment removed based on user account deletion

      • Re: (Score:2)

        by Sorny ( 521429 )
        Tesla parts are not overpriced. Tesla parts are usually sold somewhere around their actual cost at the service centers. OTA updates are free; OTA upgrades (like acceleration boost, or FSD) are paid.
  • Nav and time, I have a phone for that. No need to up the cost of the car. Plus I get updates from Google for free and a new phone whenever.

  • The clocks in question are in the GPS units.

    I assume the GPS unit is update able (the roadways have changed in the last 18 years).

    The GPS likely has a way to update the programming, not just the road info.

    BUT it probably requires going into the dashboard to access the unit, something Honda is loathe to do for an 18 year-old car.

    Bottom line the GPS is getting accurate time from GPS birds, but interpreting it wrong - is anything other than the clock display actually affected?

  • this is not very Acura.
  • Same symptom on a 2004 Toyota Avalon. "Fixed" by setting the date to 2011, which has the same pattern of days (so as to correct the day name display, as it seems to serve no other function beyond providing that information).
    • I should also note that this car has a fairly basic information console, and this sort of thing is entirely unsurprising at its age.

Slashdot Top Deals

Behind every great computer sits a skinny little geek.

Close