What Is The Year 2038 Problem?
Also known as the Y2K38 Bug, The Unix Y2K Bug or Epochalypse
The year 2038 problem is a problem caused by how some software systems store dates. When these dates reach 1 second after 03:14:07 UTC on 19 January 2038 they could have an error or incorrectly store the wrong date (in some cases 20:45:52 on Friday, 13 December 1901). To understand why this happens we need to understand the background behind how these dates are stored.
Which Dates Have This Issue?
One of the many ways dates are stored in a system is called a Unix Timestamp, Unix Epoch time or sometimes just referred to as a timestamp. These dates are stored as the number of seconds that have elapsed since midnight on 01 January 1970 (UTC/GMT).
If a signed 32 bit Integer is used to store this type of date it will run out of space to store dates after 03:14:07 UTC on 19 January 2038. This could cause an error or store an incorrect time depending on the language it was written in (for example PHP or C), the version, operating system and many other factors.
It’s important to note that this problem does not just impact UNIX systems as many programming languages and systems adopted this date format to represent time.
If you don’t understand what an signed 32 bit integer is we suggest you have a read our guide Learn How Computers Store Integer Numbers.
How Do I Check If This Will Be A Problem?
Checking for this issue across a whole system is probably going to be a time consuming and complicated task. You will need to look into all aspects of your system and everything that is connected to that system. It’s important to note that these problems may occur earlier in some systems and later in others if the system is comparing times in the future and times in the past.
All systems are different and it would be impossible to come up with a full list of things to check but here are some things to look out for:
- Embedded systems that may store dates as signed 32 bit integer timestamps
- Hardware running 32 bit software or operating systems
- Databases that have timestamps stored as signed 32 bit integers
- Database functions that use 32 bit integer representations of times such as UNIX_TIMESTAMP()
- Code where dates, times or intervals between two times are compared
- Code that calculates based on times or events in the future or past. (For example a loan calculator that calculator interest over 30 years)
You will need to rely on experts to check all the systems especially if you have critical software running that you absolutely can’t afford to break for any amount of time.
If you are running all 64 bit software this does not guarantee you won’t have any issues. Even in these systems dates can still be stored using a signed 32 bit integer and these systems could rely on other systems that may have this issue.
It’s also important to note that not all 32 bit software will have this issue, in fact the vast majority of 32 bit software probably won’t have this issue. A lot of 32 bit software will store dates in special structures that can handle dates far in excess of the year 2038 but the only real way to know how the dates are stored and used in a system is to check.
A word of caution: Do not change times on servers to test, just don’t do it. If you really know what you are doing then proceed with absolute caution. When server times get out of synchronization bad things can happen. Attempt to do all your tests on testing systems and not on production servers to minimize any impacts and if you absolutely need to test things on production machines do them at times when the systems aren’t as busy in case things break.
How To Fix This Issue
There is no universal fix to this issue. Systems will have to be fully checked and problems identified and fixed. It is suggested that you add extra tests with boundary tests around this date to ensure that the software will function after this date.
Once problems are identified here are just a few different ways they can be fixed:
- Convert the timestamps and functions to use 64 bit integers (and ensure the functions can handle 64 bit integers correctly)
- Convert the code to use unsigned 32 bit integers where you don’t need to store dates before the year 1970. Note that you will just be moving the same problem forward to the date February 7, 2106
- Convert the timestamps to use structures specifically made to handle dates and times (i.e. DateTime objects).
Is This Similar To The Y2K Bug?
In a way it is a similar type of problem to the Y2K bug in that the date is stored in a way that doesn’t have a big enough capacity to represent the time after a specific date. It is this similarity why sometimes it is referred to as the Y2K38 Bug. The Y2K bug was an issue when years were stored as ‘00’ instead of ‘2000’ whereas the year 2038 problem is the problem with the underlying structure not being big enough to hold the date after 2038.
Will This Cause The End Of The World?
Probably not. By the year 2038 most software should be updated to use at least a 64 bit representation of timestamps. For critical systems the vast majority will have to check their code bases and systems and implement any fixes well before this date. In addition to this, most of the work done to fix the issues around dates for the Y2K bug before the year 2000 should have factored in the year 2038 problem into their fixes.
This doesn’t mean that you can just ignore it but unless there are some very big oversights or companies ignore the issue most things should change over smoothly.
Conclusion
As we have seen this issue could impact many different systems in many different ways.
To ensure that you have a smooth functioning system after the year 2038 it is important that your code bases and any connected systems (including embedded systems) are tested and checked to ensure they are compatible with times after this date. With some checking and testing you can ensure your systems will function correctly after these dates and well into the future.
More Resources
https://en.wikipedia.org/wiki/Year_2038_problem
Disclaimer
All information on this website is for general informational purposes only and is provided in good faith, however, We make no representation or warranty of any kind, express or implied, regarding the accuracy, adequacy, validity, reliability, availability or completeness of any information on the Website.
Under no circumstance shall We have any liability to You for any loss or damage of any kind incurred as a result of the use of the Website or reliance on any information provided on the Website. Your use of the Website and Your reliance on any information on the Website is solely at Your own risk.