curlyptc

Wow! Changing the column attribute to unsigned did it. THANK YOU!

On that unixtime page, the one that's calculating values larger than 2147483647, I added an update query to enter that value in a record. Even though the field isn't a date or time field, again it enters a max of 2147483647. I then checked to see what type of variable PHP was making that number, and it was an integer. SOMEWHERE something at the server is saying "Oh no, the max for this number is 2147483647.

I actually define the column in the table as a 15 digit integer. I don't define it as a date field in any way. In both the page that works to go past Jan 2038, and this one that doesn't, I use the same technique, either mktime() or strtotime(). In the one that doesn't work I then try to insert the value into the table.

I've been using unixtime on my web pages for decades. And I have always known there is a limit to how far in the future I can use it... specifically Jan 19, 2038. I noticed the other day, though, that a page I created to create and process unix times was allowing me to go beyond that date. It's here and not password protected... http://www.widgetseniority.com/unixtime.php. However, thinking it was now allowed, I attempted to add a field to a table in a MySQL database that showed unixtimes for dates, many of which would go beyond Jan 2038, and when I used mktime() to calculate them, it had that max limit. Both these pages are on the same server. Any ideas why one might honor the limit, and the other not? I asked the help desk of my web host, who are normally wonderful, and they punted it, saying it was an issue for PHP experts.