You are using a browser which is not compatible with CSS (for more information, see Tara's tutorial).
Because of this, it is possible that our website may not appear
correctly in your browser. We apologise for the inconvenience, and
recommend you upgrade your browser to one which is compatible with CSS.
For more information, please visit our Browser Upgrade page.
Well the problem has already arisen at PCs which use times in the future, its called the Y2K38 bug as an allusion to what you mentioned, what may be possible is that they implement integers of 64 bits which will do the work very nicely, it will still have another limit but it will be far after we die xD
But the rest remains the same. 64-bit system is the solution.
thanks
123456789
simple $time #unix reg
My teammate was working on migration of guestbook comments from Access database to MySQL database.
The problem faced was with migrating a DATETIME datatype to integer.
This gave us an idea of what is happening behind.
Thanks.
There is a solution for the 2038 thing - 64-bit. The reason you get the rollover is that that number is the highest you can fit in a 32-bit integer. By 2038 we should all be on at least 64-bit systems, which can handle much bigger numbers. No worries.
In php:
$unix_time = 1256571985;
echo date("Y-m-d H:i:s",$unix_time)
Anything above (e.g. 10737418240) goes back to 1900.
So Linux will self destruct on Tuesday in January 2038? Surely there must be a contingency a la Y2K switchover.
-100 = Wednesday, December 31st 1969, 23:58:20 (GMT)
I had to go to another site to convert hex to decimal, and then was able to plug the decimal value in to your site. A capability to input directly in hex would be useful.
Add a new comment