In a nutshell, the answer is yes, most mobile devices have Y2038 issues, and will continue to have such issues, likely up to and including in 2038.
Most mobile devices today are based on 32-bit technology, but there is a major shift underway in the mobile device markets to move to 64-bit technology. Some high-end devices are already using 64-bit microprocessors. Chances are good that the majority of cell phones and tablets will contain 64-bit processing chips by 2038. However, using such chips does not solve all Y2038 issues, for several reasons. First, 64-bit processing chips contain multiple cores, some of which may be 32-bits. As a result, there may be Y2038 issues in the embedded system firmware exchanging dates and times between 64-bit and 32-bit cores.
Another reason why mobile devices may have Y2038 issues in 2038 has to do with the way the fact that mobile devices require precise time synchronization with the current time and may have no easy way for developers to test their applications with future dates.
The Global Positioning System, or GPS uses a raw date format which consists of 13-bit ‘number of weeks’ field and a ‘seconds into the week’ field, using an epoch of Jan 6, 1980 at 00:00:00 (UTC). The ‘number of weeks’ field will rollover after 8192 weeks (157 years), so GPS itself should not have any date/time issues until the year 2137. However, Y2038 issues may exist if the raw dates/times from GPS are improperly translated to other date/time formats, or translated to formats such as 32-bit signed integer which inherently have Y2038 issues.
See the wiki page for GPS here for more details.
Our definitions are:
Y2038 compliance means that a given system will not have Y2038 issues to at least a specified date beyond 2038.
Y2038 certification means that an organization has certified that a given system will not have Y2038 issues and is certified to function without date-related issues to at least a specified date beyond 2038.
At the moment, there are no (known) official or even unofficial industry standards for Y2038 compliance/certification. It would be a positive development for such standard(s) to be created, and we at Y2038.com are interested in participating in the standard(s) development process. Let us know if you are also interested. Perhaps we can get the ball rolling through a grass-roots effort.
The Java date class uses a 64-bit long for seconds, so Java itself should not have a Y2038 issue. However, Java may interface directly with the system on which it is running to get the current time. If the system itself is not Y2038-compliant, then Java apps may experience Y2038 issues. This will generally be the case for Java running on 32-bit embedded systems. Furthermore, there could be issues with file systems and communication protocols. Just as with all other software that use time in any way, Java applications will need to be checked for Y2038-compliance. See this stackoverflow link for some additional insight.
Of course, the answer is highly dependent on the code in question. Software that uses time extensively will obviously require more changes than software that doesn’t use time as much. As a rough guideline, it has been estimated that ~6% of all source code needed to be reviewed for Y2K issues. The percent of source code that needs to be reviewed for Y2038 should be around the same. But also realize that Y2038 may impact stored data in databases, file systems, network protocols, etc., so the issues may extend well beyond just the code itself.
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.
Crazy as it sounds, this question comes up a lot when discussing Y2038. There are many reasons to care about addressing Y2038. For one, your children and grandchildren will hopefully be very much alive in 2038. Also, not addressing Y2038 could literally cause catastrophes. Consider how shortsighted our generation (and our parents and grandparents for that matter) will seem to our children when they are faced with the staggering burden of addressing Y2038 (and potentially recovering from avoidable catastrophes if the issues are left unaddressed).
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.
The worst-case Y2038 scenarios are roughly the same as those predicted for Y2K. In fact, the chance of catastrophic events is much greater for Y2038 than Y2K since Y2038 is fundamental to the representation of time within computers, whereas Y2K was mostly just an issue of time interpretation by humans.
The absolute worst case scenario is one in which all infrastructure components simultaneously and completely stop working, including power utilities, transportation, satellites, communication, Internet, banking, commerce, medical devices, etc. Electric power plants could go off line. Nuclear power plants could experience core melt downs. Military munitions could misfire or become non-functional. Cars, planes, trains, boats, submarines, etc. may not start, fail abruptly, or behave erratically. Global communication could come to a halt. The Internet could entirely or partially stop working. Satellites may cease to function and possibly fall out of orbit. Many devices with embedded computers may malfunction, including cell-phones, pace makers, ATMs, and stop-lights. Non-compliant databases could easily cause a fair amount of confusion until the problems are resolved.
Fortunately, there is still plenty of time left to address all of these potential issues so that hopefully no major catastrophes occur.