Y2k37 Bug

214-748-3647

This phone number was showing up almost every time one of the beta-testers of my software was entering a phone number – regardless of the actual phone# they had entered.

Naturally, my first instinct was to search around the codebase for anywhere that value might have been hard-coded. Nope. Nada.

I thought some more about the problem; what is actually happening at or around the time I save the value to the database? I am converting the string value to an INT to save to a DB2 table as a numeric type (stripping out any non-numeric characters). Then simply doing my routine save() call to write the value to the database. It was working fine on my development environment. Pretty straightforward.

Thinking some more about it; one difference between the production system (where the beta-testing takes place) and my local development environment, is the 32-bit (production) and 64-bit (on my local dev) Linux OS. Hmmmm……

Turns out, the problem was occurring during the conversion to an INT, using PHP’s intval() function. The maximum allowed 32-bit integer is… you guessed it…. 2,147,483,647. Anytime users entered a phone number with a numeric value greater than this, intval() would return the maximum value. A quick scan of the manual here: http://php.net/manual/en/function.intval.php confirmed my suspicion (see section under Return Values)

My solution was to take off the intval() call, since my DB2 doesn’t mind if you insert a string into a numeric field (as long as it really is numeric) – it will do the conversion during the write.

I did a little follow-up research on the 32-bit INT restrictions, thinking I can’t be the only one to have encountered this issue, and I was right. The biggest concern is related to UNIX timestamps, we are literally running out of time for using 32-bit OS! Check out this article for more: https://en.wikipedia.org/wiki/Year_2038_problem