19-01-2007: a 31 años del efecto 2038

1. #50   En las todas las versiones de 64 bits de Linux (y glibs), el time_t es de 64 bits y no tendrá ese bug, confirmado empíricamente con el programa de abajo.
   
   En meneame.net (64 bits):
   $ perl test.pl
   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
   Tue Jan 19 03:14:08 2038
   Tue Jan 19 03:14:09 2038
   Tue Jan 19 03:14:10 2038
   
   En uno de 32 bits:
   $ perl test.pl
   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
   
   ––––––––––- el test definitivo––––––––
   #!/usr/bin/perl
   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 Gregorian calendar for each result.
   # Are the date and time outputs correct after the critical event second?

   86  votos: 11  

   el 19-01-2007 00:19 UTC por gallir