Y2038 Problem (similar to Y2K)
Short Answer:
"Y2038 refers to an issue related to the way time is handled by computers. Time is often represented as the number of seconds since Jan 1, 1970. Whenever a 32-bit signed integer is used for this, the maximum value that can be represented is +/- ~68 years, 19 days from the epoch, which corresponds to Jan 19, 2038. What happens after that is system dependent, but generally not good. A computer may act as if its time got reset to Dec 1901, or possibly to the epoch of Jan 1, 1970. It may give unexpected results or crash.

Basically, any software that uses time in any way may potentially have Y2038 issues. While only a small percentage of each software component is typically affected, this is still enough to cause many problems. Embedded systems with 32-bit cores and computers running 32-bit versions of Linux and Windows and are particularly at risk, but even 64-bit computer systems may have problems. In 64-bit computer systems, time can be represented in 64-bit integers, but Y2038 issues may still exist in applications, device drivers, databases, storage systems, and network protocols."

More Information -

Quite a well known fact in the technology world and actually there are a few systems being dealt to mitigate the issue
"I'm a gamer, not because I don't have a life... But because I choose to have many"

Hi...I was creating some keys and certificates with openssl to use for secure client server communication over the net. This is actually part of a project to get my Propellers on the WEB so you will be interested one dayAnyway, when you create public keys/certificates you can specify a time span, in days, for which they are valid. After that they expire and can no longer be used. I set the time span to 9999 days which means they should expire some time in 2040.The certificates created by openssl did not work. Eventually I discovered the certs were set to expire in 1904.

pcb assembly

To be honest I think Y2038 will be even less of an issue than even Y2K was as it would be easy to fix in software by just changing the epoch to normal time calculations, for example 0 epoch time would become 2020 rather than 1970.

This is actually the first I've heard of this but I'm not particularly worried about it. The Y2K bug ended up being very minor for how much it was talked up. It seems there is even more time to prepare for the possibility of the bug you mentioned then there was for the Y2K, so I have a feeling we will see very few effects.

Users browsing this thread: 1 Guest(s)