Y2K38 : Overflow del tiempo en 32bits
En algún lugar entre tantas cosas que leo me encontré con una referencia a una gran catástrofe informática que ocurrirá en el año de 2038, esto es mejor conocido como el Y2K38 o Unix Millennium Bug. Aunque en el post que he leído se hacia mención únicamente a un error en PHP, me he llevado la gran sorpresa al enterarme que este problema afectara mucho más que a PHP y los sistemas desarrollados para la nube, afectara a todo sistema basado en UNIX y plataformas de 32 bits, lo que en si engloba una gran cantidad (casi todos) de sistemas informáticos implementados por todo el mundo.
El gran problema
La mayoría de sistemas están soportados en SO y plataformas de desarrollo que utilizan tecnología de 32 bits para su procesamiento y almacenamiento. Estos sistemas utilizan una variable de tipo time_t el cual puede almacenar un entero de 32 bits con signo, en esta variable se almacena la cantidad de segundos que han transcurrido desde el 1 de enero de 1970 (a las 00:00 hrs.), esto también conocido como SISTEMA POSIX, debo aclarar que por mas que he buscado un porque para la referencia exacta a esta fecha no la he encontrado.
Por ser una variable de 32 bits, esta podrá almacenar hasta el 2.147.483.647, numero que será alcanzado el 19 de enero de 2038 a las 03:14:07 UTC… que pasara luego? Es algo que según textos variara dependiendo de la implementación, pero lo normal será que este valor se resetee o de un error de compilación (también es posible que tome su mismo valor pero negativo).
Hablemos de PHP
PHP es otro de los grandes lenguajes que probablemente tendrán su overflow al momento de llegar esta fecha ya que se basa en el mismo sistema para gestionar su variables de fecha. Podremos comprobarlo ya que si realizamos la impresión simple de la función date() este mostrara el entero correspondiente al tiempo Unix, recordemos que a esta función le enviamos un formato para su impresión.
Para saber si seremos presas de este bug, podremos correr un código en el cual le solicitemos una fecha superior a la fecha máxima y cruzando los dedos para que muestre la correcta, en mi casi esto no ha sido así 
$date = ‘2040-02-01′;
$format = ‘l d F Y H:i’;
$mydate = strtotime($date);
echo date($format, $mydate);
// // Thursday 01 January 1970 00:00
Conclusión
Talvez los recuerdos de un sobrestimado Y2K me haga suponer que la gran catástrofe del Y2K38 no será tan grande o tan impactante como es conocido, a esto debo sumar el gran factor de cambio que están sufriendo nuestras tecnologías donde poco a poco veremos como muere la tecnología 32bits para darle paso a la de 64bits, la cual en este bug específicamente nos dará un poco mas de tiempo (unos 290 mil millones de años ¬¬), así que desde mi punto de vista no hay que preocuparnos en lo absoluto por esto, seguramente tendremos Bugs mas importantes que haran pedazos nuestros sistemas 
Programador Web, Visionario, Idealista, tratando de no tirar mi vida y buscando ALGO MAS todo el tiempo, medio geek, medio loco, con ganas de EXITO...
Como tu conclusión lo dice, posiblemente no cause un impacto como los que se pronosticaban con el y2k, que hasta lo relacionaban con el fin de la informática-[Exagerados]. En caso contrario, para php si este bug causará tanto daño como lo describen, estará surgiendo en una etapa avanzada en el que habrán equipos de depuradores que desarrollará algún debugger.
Para la parte en la que se ve afectada la variable time_t pareciera que la mejor opción es utilizar sistemas operativos de 64 bits cuyas arquitecturas ya utilizan enteros de 64 bits en sus time_t, eso por el momento.