Y2K38 - Unix Millennium Bug - Solution

Then, What would be a solution ?

Fortunately, PHP introduced a new DateTime class in version 5.2 (experimental support was available in 5.1 and be aware that some methods were introduced in 5.3). Just execute the following program which will display the correct date time.

<?php
$date = '2040-01-20';
$format = 'l j F Y H:i';
$mydate = new DateTime($date);
echo 'DateTime Class : ', $mydate->format($format);
?>

Output will be,
DateTime Class : Friday 20 January 2040 00:00

There have been many solutions proposed worldwide for this problem.
Few of them are listed here.

> Re-define the time_t structure as 64-bit.

This is not a solution as the binary compatibility of the software would break here. Programmes depending on the binary representations of time would be in trouble. So we can not even think of this one.

> Change time_t from 32-bit signed to 32-bit unsigned.

This seems to be good at first look, but this would just delay (post-pone) the judgement day to the year 2106 as it will give some more scope by adding another usable bit. You will be in the same trouble by then. So this is a feasible solution but not a practical one.

> Shift from 32-bit systems to 64-bit systems.

Most 64-bit architectures use 64 bit storage to represent time_t. The new wrap-around date with this new (signed) 64 bit representation will not come before 290 billion years. It is positively predicted that by the year 2038 all 32-bit systems will be phased out and all systems will be 64-bit.

Read Other Parts Of This Post :
Y2K38 Unix Millennium Bug : Introduction, How To Check This Bug, Solution