Honda cars in flashback to 2002 – “Can’t Get You Out Of My Head”

Owners of Honda cars of a certain age – apparently somewhere between 10 and 16 years old – have spent the first few days of the New Year reporting a weird “millennium bug style” problem.

Apparently, for many cars that are a decade or so old, New Year’s Day 2022 was ushered in with their in-car clocks…

…showing 01 January 2002, exactly twenty years in the past.

In case you’re wondering what life was like back then, it probably won’t help to be reminded that one of the top songs of the year was the unforgettable Can’t Get You Out of My Head, by Aussie superpopstar Kylie Minogue.

(As Kylie said at the time, “La la la, la la la-la la/La la la, la-la la la-la” – a refrain that still ranks, according to some studies, as one of the top earworms in history.)

But why?

The burning question is, “Why?”

In the infamous millennium bug, the error jump was 100 years, and the reason was obvious: programmers often used just two digits for the century (i.e. storing AD1999 as 99) as a simple shortcut to save on RAM and disk space.

Don’t forget that even by 1999, most computers had just a few megabytes of RAM, and 20 years before that, they had at most a few kilobytes, amounts that are a jaw-dropping one thousand and one million times smaller than we take for granted today.

But every shortcut comes with a cost, and the Y2K shortcut paid the price that, because 99+1 = 100, and because 100 crammed into two digits comes out as 00…

…people were afraid that the date 31 December 1999 (Baby One More Time by B. Spears) might confusingly be followed by 01 January 1900 (I Can’t Tell Why I Love You But I Do by H. Macdonough).

But why just 20 years in Honda cars? Why only in certain older-but-not-too-old models? And why two decades exactly?

Even more weirdly, why would Honda say, as some journalists are alleging:

We have escalated the issue of the navigation clock in our team of engineers and they informed us that you will face the problem from January 2022 to August 2022 and then it will be fixed automatically.

Let the guesswork commence

One good guess, backed up by a commenter on UK IT news site El Reg (The Register) who goes by VRocker, is that this particular glitch is GPS-related

Until recently, GPS time data – based on ultra-precise time signals beamed out by an array of orbiting satellites designed in the 1970s, when every individual bit of bandwidth really counted, let alone every decimal digit – was limited to a date window 1024 weeks wide.

Where Y2K-constrained dates had a maximum of two decimal digits for the year number, limiting them to a decimal century…

…GPS timecodes originally had just 10 bits (bit is short for binary digit, by the way) for the week number.

And in 10 bits you can represent numbers from 0 to 1023, giving you a 1024-week period (a “Kiloweekary”, we’ll call it) that covers nearly, but not quite, 20 years.

We’re currently in the Third Kiloweekary of the GPS era:

   First Kiloweekary:   1980-01-06T­00:00:00Z - 1999-08-21T­23:59:59Z
   Second Kiloweekary:  1999-08-22T­00:00:00Z - 2019-04-06T23:59:59Z
   Third Kiloweekary:   2019-04-07T00:00:00Z - 2039-11-20T23:59:59Z

Glitches may be relative

Of course, if your software – like the automatic time-setting software in many navigational devices – relies on GPS dates of this sort, you don’t inevitably suffer from computational wraparound glitches only at the exact changeover points betweem the Kiloweekaries listed above.

You aren’t locked to precisely the date ranges shown, but rather to the maxumum length (7168 days, or 1024 weeks, or about 19 years 7½ months) of each range.

That’s because you can add or subtract any offset you like to or from the starting point of each Kiloweekary, and do your own 19.6 year relative calculations from your new starting point.

This is the same trick that that many old-school programs did with two-digit calendar years: some software, for instance, allowed you treat 00-49 as representing AD2000 to AD2049, with 50-99 representing AD1950 to AD1999, thus shifting that software’s “millennium bug event” along by 50 years.

The Reg commenter called VRover whom we mentioned above claims that the GPS itself (not the clock) in his Honda CR-V is reporting that it’s currently May 2002 (which is, as he points out, 1024 weeks ago), while the clock is essentially stuck at 01 January 2002.

(According to reports, it seems that the clock resets to a time of midnight, modulo your timezone, on a date 01 January 2002, every time you restart the vehicle, regardless of the actual time of day; after this, the time can’t be adjusted manually.)

Rollover in the picture

That GPS detail is what led VRover to infer that this behaviour does indeed relate to a recent rollover of the Kiloweekary date range inside Honda’s software.

But why did the clock roll back in January 2022?

And why the auto-correction implied by Honda in August 2022?

VRover’s sugestions is that on 2022-08-17 by his calculation (this coming August), his rolled-over GPS date (which currently sits somewhere in May 2002) will think that 2003 just started.

And if the clock software is set so that it assumes it should disregard the time and date offered by the GPS unit if the year comes out earlier than 2003, in one of those “something must have gone wrong” error situations, then at least the time displayed – but not the date! – may well correct itself as suggested by Honda when the car thinks it has once again reached what it thinks is a valid date range.

We’re guessing liberally now, but if we assume that whoever created the software used in the affected range of vehicles knew that the first version definitely wouldn’t ship until 2003, then they’d know that using a Second Kiloweekary that represented its regular date range (from 1999 to 2019, as listed above) would waste the first few years of available dates.

But if they simply shifted the starting offset of their date range by 1000 days, they could then use the first 1000 days of the official GPS Kiloweekary (which would already be in the past when the unit shipped) to denote an additional 1000 days at the end of the range.

In other words, if they decided to use the dates from 1999-08-22 to 2002-05-17 (a 1000-day period) to represent the first 1000 days of the THIRD Kiloweekary instead of the first 1000 days of the SECOND Kiloweekary (much like a Y2K coder electing to use 00-19 to represent AD2000 to AD2019 instead of AD1900 to AD1919), they’d be able to represent dates in the following ranges:

   2002-05-18 - 2019-04-06  and  2019-04-07 - 2021-12-31

In simple terms, they’d be able to cover all years in full from 2003 to 2021 inclusive, with their “sideslipped” Kiloweekary ending conveniently on the last day of 2021 instead of mid-April in 2019.

If, therefore, as VRover suggests, the clock software was coded simply to discard the year 2002 (which is incompletely covered, and could in any case never be correct if the first units didn’t sell until at least 2003), and to default back to 01 January of that year if it ever faced dates outside the supported range…

…then his GPS date would indeed have flipped back from 2021-12-31 to 2002-05-18 when New Year arrived, which is a symptom he says he observed.

And then his clock – assuming that the sudden “reappareance” of 2002 would imply rollover or some other error – might thus repeatedly default back to 2002-01-01, in the same way that many digital oven clocks decide it’s exactly noon o’clock every time there’s a power failure.

What next?

Or course, if VRover is right about this – and we have no way of telling until Honda makes an official statement – then when his GPS thinks it’s 2003, his clock will start accepting the “sideslipped” data provided by the GPS once again, and the clock will start working, but although the time will be correct, the date won’t.

(Indeed, if VRover is right, his clock will start keeping time, and not resetting to 01 January every day, starting from 17 August 2022, but it will show the date commencing at 01 January 2003 from that point.)

And if that part of his guesswork is correct, the code in the clock that figures out daylight saving will be confused – presumably thinking it’s the Greenwich Mean Time period of the year (November to March in the UK), when in fact it should be the British Summer Time period (April to October), with the clocks turned forward by an hour.

What’s your explanation? How will this pan out? Let us know in the comments below…

(How time flies when you’re having fun!)