It totally depends on your needs. For new projects, the incremental cost of a requirement for Y2038 compliance (without using outsource staff) is probably trivial relative to the cost of the project. But if you have a significant existing portfolio of products and complex business systems, outsourcing may be a viable option to help with Y2038 assessment and/or mitigation, thus freeing up your prime in-house developers to continue working on forward looking projects instead of date/time issues.
Here are some actions that you can consider taking now:
Designate a Y2038 Compliance Officer to serve as the company focal point for Y2038 compliance. This position may or may not be full-time depending on the size of the company. The person in this position could, for example, report to a senior officer, and also chair a committee comprised of directors/managers or representatives from every major division in the company. The person in this position will be responsible for keeping documentation on compliance findings and status.
Implement corporate policies for Y2038 compliance. For example, a policy may require that all new projects be designed, tested, and maintained for Y2038 compliance if at all possible. The policy can further require that exceptions be formally documented and approved, thereby enabling them to be tracked and addressed sometime later.
Start assessing your company’s level of exposure to Y2038. This should include all digital systems used or produced by your company, from the largest business system to the smallest embedded system. It should also include all databases and storage systems, third-party and developed system and application software, and any custom network protocols. When issues are found with third-party products, you should contact those vendors and request that they update their products to be compliant.
Budget for Y2038. The above actions cannot happen without a financial commitment from management. Postponing these actions also has a cost, likely much higher than you expect. The cost is not just money… it is also time (since issues will take longer to fix later) and employee satisfaction (since developers generally want to work on new things, not on date issues in old systems). Budgeting now will save money in the long run.
It depends. One factor is the life-cycle of your products. For products with life-cycles of 20+ years, you should start preparing now. For shorter life-cycles, you may be able to wait until your next development cycle, and then make Y2038 compliance a requirement.
Another factor is your business infrastructure. Most companies have business infrastructure tools and data which may have been developed in-house or purchased/leased from third-parties. These systems may be quite complex and may have taken years to deploy. The original developers may or may not be available to assess or mitigate Y2038 issues. Therefore, the assessment/mitigation effort may be large and may include migration of data. Companies that wait too long to prepare will be competing for limited technical resources as 2038 approaches and may find it difficult to secure the resources in time at a reasonable cost, thereby putting the business itself at risk.
The main point is that the Y2038 effort should not be underestimated. It is far better to proactively assess and mitigate as early as possible.
Purchasing new hardware and software is a pragmatic and relatively simple part of an overall Y2038 compliance strategy, but there are also many legacy issues to deal with, such as existing databases, file systems, and communication protocols with binary 32-bit data fields for time. Furthermore, 64-bit systems are capable of running 32-bit software, either directly or within virtual environments, and these may not be Y2038-compliant. There is also the issue of all internally developed software for business use and contained within products which may have Y2038 issues, but that can’t simply be purchased.
Indeed, virtually all new servers, desktop, and laptop computers being sold today have 64-bit hardware and operating systems. Some high-end cell phones and tablets also have 64-bit hardware and operating systems. However, the hardware and operating system are only part of the Y2038 issue. There are many other technical areas where Y2038 issues may exist, including application software, peripheral hardware, device drivers, file systems, databases, communication protocols, web content, and embedded systems. Computers with 64-bit hardware and operating systems are capable of running 32-bit software which may not be Y2038-compliant. Even 64-bit software may not be Y2038-compliant.
It is also important to consider that most of the billions of embedded systems today and likely trillions that will exist by 2038 will still be using 32-bit (or less) CPUs due to factors such as power usage and the higher cost and complexity of 64-bit CPUs. Many embedded systems will not experience Y2038 issues, but a significant portion of them may.
There may be several reasons. One reason is of course that the Y2038 event seems so far off. Being over 20 years away, there is no sense of immediate urgency to fix anything. However, this is the same type of thinking that was partly responsible for the creation of the Y2038 issue to begin with.
Another reason you may not have heard about Y2038 is probably due to the extensive media coverage that preceded Y2K. Perhaps in part due to the heightened awareness by mainstream media, the Y2K issue was almost fully mitigated prior to Jan 1, 2000. When Jan. 1, 2000 arrived, there were no catastrophes, and there was a public sense that the Y2K event had been over-hyped. In fact, it is likely that the extensive Y2K media coverage forced businesses to thoroughly and proactively address it. (Chances are, media coverage will similarly increase before 2038).
Yet another reason may be a general lack of understanding of Y2038. Y2K was fairly easy to understand, but Y2038 requires a deeper understanding about the digital representation of time in computers.
It depends. If your company’s products and/or services use time and have a 20+ year life cycle, then the answer is definitely yes. Examples are satellites, power plants, airplanes, trains, elevators, pace makers, life insurance, and mortgage services. If your products have a much shorter life cycle, then you still have some time. Just realize that the results of many projects may get used for longer than expected.
We suggest making Y2038 compliance a requirement for all new projects, and test for it. Starting early allows plenty of time to identify dependencies on third-party products and contact those vendors for Y2038-compliant replacements, or find alternate vendors. It is much better to be proactive about Y2038 compliance rather than waiting for customers to discover issues.
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.