HallmarcDotNet

Marc Elliot Hall's Blog

Headlines

Christmas card is up Check out the Flash...

Blog-o-licious We've got blogs...

Site Redesigned HallmarcDotNet has a new look...

 

Welcome to My Weblog

— also known as my vanity gripe page

I'm currently available for your project! Please view my résumé and Open Letter to Recruiters if you are looking for an experienced, senior technical manager, project manager, business analyst, team lead, software engineer, web application developer, webmaster, system administrator, technical writer, or technical editor.


Tue, 29 Apr 2008


"And to think your [sic] paid for this"

The Looming Y2K38 Crisis

Following is a demonstration of how easily distractible I am.

A few months ago, I was doing a little training of some co-workers, and wound up composing this email:

Marc Hall/STL/MASTERCARD
01/14/2008 02:07 PM

While explaining to our newest team members this morning how [edit: redacted project name] works, I ran off on a related tangent about Unix timestamps formatted in seconds since the beginning of the Epoch. This further sent me off on a tangent about how Unix keeps track of time. This reminded me of the Looming Y2K38 Crisis.

In case you are unfamiliar with the idea, Unix keeps track of time by counting seconds since January 1, 1970. This is known as the beginning of the Unix Epoch. Today, around 1,200,160,000 seconds have elapsed. The seconds are represented in 32-bit Unix and unix-like systems by a four-byte integer value. Because a four-byte signed integer has a maximum decimal value of 2,146,483,547, on January 19, 2038, 03:14:07, Unix will run out of bits to store our seconds.

And time will stop.

No, seriously, either systems relying on the time will terminate in unpredictable ways, or the apparent time will wrap around back to January 1, 1970.

This is bad, for reasons left as an exercise for the reader.

Some time (ha!) between now and 2038, someone will have to go through every line of code in the Unix universe and validate that on the rollover date the system will not crash or behave unpredictably. This will be a project with a scope similar to the Y2K-bug-stomping-frenzy that concluded last century. It will make the DST patching we did after Congress last altered timekeeping look like making mud pies. Programmers specializing in Unix will be dragged kicking and screaming out of retirement and handed large sums of cash to evaluate critical systems. And, in the end, after months of trepidation and hype, January 19, 2038, will be a non-event -- Because, like the Y2K Crisis, enough people will really understand how bad it could get if systems are left unpatched, that adequate time and resources will be allocated to be sure that everything is fixed in time.

Some have predicted that all 32-bit Unix systems will be long since retired by 2038, and 64-, 128-, 256-, 512-bit systems will have eliminated this as an issue. However, I have personally dealt with embedded systems more than 20 years old already. I expect there are 8-, 16-, and 32-bit embedded systems out there right now that will still be in use in 2038. Traffic signals. Assembly line controllers. Communications equipment. A lot of these run on 32-bit Unix-like kernels. In addition, there will still be business software running in emulated 32-bit environments, too, much like MasterCard is still using mainframes long after Microsoft's predicted migration to all-Windows-all-the-time. Legacy systems have a way of hanging around.

You heard it here, first!

More info (so you know I'm not just making stuff up):
http://www.y2k38.info/index.html
http://home.netcom.com/~rogermw/Y2038.html
http://www.hackosis.com/index.php/2007/12/21/linux-is-not-y2k38-compliant/

The Boss' Response ...

And to think your [sic] paid for this:(

... And My Reply to the Boss' Response

Hey, I'm just developing my career potential :-)

After all, Consultant-level --- no, Senior Consultant-level --- work requires strategically-oriented, thought leadership about the company's long-term outlook and anticipation of future events that will affect business operations at the limits of the planning horizon. The ability to assimilate, internalize, and communicate these strategic issues is what separates the Senior Consultant from the Engineer.

Further, if training dollars are not available, then it is incumbent on Senior Consultants to provide appropriate knowledge transfer to the various lower-echelon engineering staffers.

Also, I'm paid a premium for my excellent grammar ;-)

posted at: 12:18 |


Marc Elliot Hall St. Peters, Missouri 

Page created: 21 January 2002
Page modified: 14 November 2006

spacer About Us | Site Map | Privacy Policy | Contact Us | ©1999 - 2006 Marc Elliot Hall