Preparing for Y2038 (Already?!)
It somehow doesn't seem that long ago, but nineteen years ago during Y2K I spent my New Year's Eve in the Akamai Network Operations center, waiting to respond to anything that might go awry as the clock struck midnight in key time zones such as Greenwich and Boston. As of January 9, 2019, we are roughly half-way from Y2K to "Y2038", the next large time epoch roll-over event. In 2038 on January 19th the "Unix Epoch Time" will exceed the size of a signed 32-bit integer "time_t" value (231-1), or roughly 2.1 billion seconds since the epoch of 00:00:00 on January 1, 1970. We have somewhat more time to deal with the systems that will break nineteen years from now. However, as we get closer there will be increasing impacts on software working with future dates.
Shortly after Y2K we made jokes about "next up, Y2038!" but back then it felt an eternity in the future and likely to be someone else's problem. Now that we're halfway there, and we have already reached the point where Y2038 issues can cause software failures, it is a good opportunity to start planning for Y2038. For example, software may already be having issues working with 20-year certificate lifetimes or 20-year mortgages, and the frequency of these issues will only increase as we get closer to Y2038. At Akamai we are already running strategically-targeted internal planning and testing for Y2038, and it seems likely that the scope of this work will continue to grow over the next 19 years as this important effort increases in urgency.
Very little went wrong on January 1, 2000 for us (short of some Javascript on an Akamai marketing site displaying "1900" as the current date!), but one thing that gets missed is that the limited global impact that evening was due to two factors: 1) the amount of advanced preparation that was done; 2) many "Y2K problems" actually occurred years in advance rather than during the roll-over itself. Leap seconds are in some ways scarier than date-format issues in that they are harder to test for and much less of the impact happens in advance. There is a risk that the lack of impacts of Y2K may cause organizations and technologists to under-prepare for Y2038. It is also harder to explain "Y2038" to lay people than Y2K, potentially making it harder to prioritize and focus advanced work. The large number of embedded Internet of Things (IoT) devices becoming ubiquitous in our environment also makes the likely risk and potential impact considerably higher for Y2038 than it was for Y2K.
- Login or register to post comments
- Printer-friendly version
- 2004 reads
- PDF version
More in Tux Machines
- Highlights
- Front Page
- Latest Headlines
- Archive
- Recent comments
- All-Time Popular Stories
- Hot Topics
- New Members
digiKam 7.7.0 is releasedAfter three months of active maintenance and another bug triage, the digiKam team is proud to present version 7.7.0 of its open source digital photo manager. See below the list of most important features coming with this release. |
Dilution and Misuse of the "Linux" Brand
|
Samsung, Red Hat to Work on Linux Drivers for Future TechThe metaverse is expected to uproot system design as we know it, and Samsung is one of many hardware vendors re-imagining data center infrastructure in preparation for a parallel 3D world. Samsung is working on new memory technologies that provide faster bandwidth inside hardware for data to travel between CPUs, storage and other computing resources. The company also announced it was partnering with Red Hat to ensure these technologies have Linux compatibility. |
today's howtos
|
Recent comments
1 year 11 weeks ago
1 year 11 weeks ago
1 year 11 weeks ago
1 year 11 weeks ago
1 year 11 weeks ago
1 year 11 weeks ago
1 year 11 weeks ago
1 year 11 weeks ago
1 year 11 weeks ago
1 year 11 weeks ago