¿Os acordais del efecto 2000?
Pues bueno, tal y como podemos leer
aquí y
aquí, el efecto que resultará en 2038 será mucho peor.
La cosa está en que, mientras que el efecto 2000 perjudicaba a todas aquellas máquinas y programas que manejaban fechas usando los dos últimos digitos, el efecto 2038 afecta a todos los sistemas operativos tipo UNIX o no, bases de datos, lenguajes de programación, etc., que manejen el tiempo en "Timestamp" en formato de 32 bits. Es decir, ese contador que cuenta los segundos desde el 1 de enero de 1970, y que podemos ver reflejado en la tira Ecol:
[Tira Ecol ~] $ Haciendo Linux divertido desde 979516800
Bueno, la cosa es que casi todos los sistemas tipo UNIX que existen hoy en día manejan esta variable con formato de 32 bits, y recordemos que hay muuuuchos aparatos basados en un sistema UNIX, incluyendo modems de cable, reproductores de DVD... incluso en sistemas que no están basados en UNIX, hay muchos programas que usan un timestamp similar, asi que...
Si quereis probar vuestro SO, en
esta página teneis un pequeño script en perl que lo prueba, que además pego aquí:
#!/usr/bin/perl
#
# I've seen a few versions of this algorithm
# online, I don't know who to credit. I assume
# this code to by GPL unless proven otherwise.
# Comments provided by William Porquet, February 2004.
# You may need to change the line above to
# reflect the location of your Perl binary
# (e.g. "#!/usr/local/bin/perl").
# Also change this file's name to '2038.pl'.
# Don't forget to make this file +x with "chmod".
# On Linux, you can run this from a command line like this:
# ./2038.pl
use POSIX;
# Use POSIX (Portable Operating System Interface),
# a set of standard operating system interfaces.
$ENV{'TZ'} = "GMT";
# Set the Time Zone to GMT (Greenwich Mean Time) for date calculations.
for ($clock = 2147483641; $clock < 2147483651; $clock++)
{
print ctime($clock);
}
# Count up in seconds of Epoch time just before and after the critical event.
# Print out the corresponding date in Gregrorian calendar for each result.
# Are the date and time outputs correct after the critical event second?
Es tán fácil como copiarlo en un fichero de texto y darle permisos de ejecución (chmod u+x).
Este es el resultado en mi Gentoo 2.6.7:
Tue Jan 19 03:14:01 2038
Tue Jan 19 03:14:02 2038
Tue Jan 19 03:14:03 2038
Tue Jan 19 03:14:04 2038
Tue Jan 19 03:14:05 2038
Tue Jan 19 03:14:06 2038
Tue Jan 19 03:14:07 2038
Fri Dec 13 20:45:52 1901
Fri Dec 13 20:45:52 1901
Fri Dec 13 20:45:52 1901
¡Doh!
Mala suerte... en Linux pasa directamente a 1901, y en otros SOs tipo UNIX directamente se cuelga.
Aún quedan 34 años, asi que es de esperar que lo solucionen un día u otro, pero... ¿que ocurrirá con aquellos aparatos que tengan un procesador o controlador de 32 bits corriendo bajo un minisistema UNIX? Esos no se pueden actualizar así como así...
PD: En Windows tambien falla, pero no por el SO sino por el interprete de Perl que tiene el mismo bug. Aún así, el límite de fecha de Windows NT es el 2184 (estaremos momias por entonces
). Apple puede presumir de representar fechas en Mac OS hasta... ¡29.940!