Has anyone thought about the Year 2038 Bug for the S2000? I figured ABS might be affected for AP1s, due to 32-bit for embededed systems, like ABS at that time. I know this is 20 years away, although I’m sure I’m not the only S2000 owner thinking about the implications of this.

From an article: “The computers that have the potential to cause the biggest issues are those embedded systems that cannot be upgraded. They are used in many transportation systems and other long-living devices, equipment such as stability control systems in cars or other isolated computer-based systems.”

https://www.theguardian.com/technolo...he-new-y2k-bug

 

Not a single stock electrical component in our cars stores the current time and date, so I don't see why we would have any problems

 

 

Ok let me elaborate on my previous post.

For a system to experience undefined behaviour because of such a bug, it needs to store and use the current date and time somewhere. For example something like a calendar app, or an (embedded) system that makes appointments or a weekly planning.
Then in 2038, the dates in these programs could get corrupted, displaying wrong dates which could maybe break the program completely.
Nothing in our cars use date and time so there is nothing to worry about, they simply do not contain this information.

Look at it from another view: even if our cars used the current date and time in one of their electrical components, to store the current date you need to save that in program memory, which would get erased if the battery in a car flatlines, just like the OEM radio clock resets after a battery disconnect.
So even if our cars wanted to and could break on purpose in 2038, they can't because they won't even know when it actually will be 2038, unless their battery has NEVER been disconnected and the correct current date and time were programmed into them from the factory.

Nothing is going to happen.

 

On that date it will think it is the first day of the epoch in 1970 and your car will cease to exist because the s2k was not made in 1970 .....

:P seriously though....

Our ECU has no idea what time it is or what date it is. It has no connection to update time even if it did (would require a network connection). ABS never has any reason to care what time it is or what the date is. It just operates by updating a register on regular intervals and producing actions based upon those inputs. Think of the clock in an ECU like ours as nothing as a metronome. It is not a clock in terms of storing the date, it just ticks away at a constant rate which controls the timing of actions by the ECU. Only applications requiring the date and time to be stored do so, and control systems like those in our cars do not need this info to operate. If they did, they would have a cell modem embedded so they could obtain network time updates. Otherwise the time would drift and be off, even if the battery were never disconnected.

And the whole 2038 issue will be as big of a deal as y2k was. While some profited by making everyone think the world would end, it was never that large of a risk and software updates simply had to be made. If they had not been made it would have caused some issues that were totally recoverable, not some world ending, bank accounts not existing, type of failure that people thought it would

 

You and Scighers brought up some great points, thank you! I was also thinking about a required power source, like a CMOS battery or resetting to 1970. Since the ECU is some type of computer, it most likely would have a 32-bit or 64-bit architecture. This is in regards to the limits of 32 vs 64 in storage and perhaps dates. A similar example is IPv4 and IPv6.

I’m still curious if anyone has tested this? Perhaps not and I’m just jumping the gun, lol.

 

Look at it this way, if the ECU is using logic that required accurate date/time info, it would have already failed on you Without a connection to a stable time source (GPS sat with an atomic clock, internet connection that also uses similar time reference which is correct) any ECU will have drift in its time keeping. This is why digital clocks in cars, even if the battery is not removed, will eventually drift. Many influences (especially in a harsh automotive environment) cause crystal oscillators even to drift. This and other issues cause the time to drift unless constantly being updated from an outside source.

ABS has no reason to care what time it is, nor do any other systems on this car. The only reason a buffer overflow in a date register would cause an issue is if the system is making calculations based upon the precise date. That is not needed for anything our ECU does.

If you want to test it, pull the battery for a day and put it back in. If the date was an issue, it would fail right there. I dont care what backup battery is in it, said battery would be all but useless after 10+ years of use in an automobile. So no matter how you look at it, it is not a concern.

 

[nitpick]
The 2038 bug is a 32-bit signed integer issue. So when the value rolls over, it goes from INT_MAX to INT_MIN, not to zero. That means for systems that store time as a 32 bit number, on Tuesday, January 19, 2038, time will roll from 3:14:07 AM GMT to Friday, December 13, 1901 8:45:52 PM GMT, not Thursday, January 1, 1970 Midnight GMT. (0x7FFFFFFF to 0x80000000, or 2147483647 seconds to -2147483648 seconds)
[/nitpick]

--Carlos V.