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

#11   A los informáticos nos conviene esperar al último momento para arreglarlo. Así se podrá cobrar más pasta.

#8   yo creo que de aquí al 2038 no existiran CPU's de 32 bit

#15   #14 Jajajajaja .... #13 Te acaban de llamar VIEJO

#30   #27 también, también, pero hablamos de operaciones a nivel de hardware, así que necesitamos que las operaciones sean lo más rápidas posibles. Hablamos del tiempo, del reloj del sistema, no podemos entretenernos en castings y demás. Si el registro trabaja a 32 bits con signo, la forma más rápida de tratar con él será usando ese mismo tipo, no? ¿Que hoy en día a los registros de las CPU's les da igual 8 que 80? De acuerdo, pero es lo que tú dices, qué iban a saber ellos en la prehistoria

#27 yo soy Einstein y tú eres tonto directamente. La máquina usa restas para comparar. Que tú no lo sepas, no es mi problema (ni el de Einstein)

#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?

#12   yo aspiro a mantener mi equipido hasta ese año ..

#25   el 2038 va a llegaaaaaaaaaarrrr

Bueno, en el caso de java no afecta supongo, entre otras cosas porque los timeticks se guardan como long y no como int. Además si fuese el caso, con actualizar la API (y no los programas) bastaría.

#31   Miradlo por el lado bueno, el día que eso suceda, todas las licencias se renovarán automáticamente.

#9   #8 estamos a 2007 y seguimos usándolas de 8 bits...

#20   Voy a ponerme un aviso en el Google Calendar para que me avise de este problema 2 años antes de que ocurra. Osea, para el 2036, yo mismo pondre de nuevo la noticia en meneame para que no nos olvidemos del problema.

#26   #24 para operaciones con diferencias horarias. Si necesitas saber si X < Y, resta Y a X. Si el resultado es negativo, X < Y, sino, X >= Y.

PD: ¿Y tú estás en la FIB, mangurrián?

#7   #4 el efecto 2000 no se notó porque se arregló a tiempo. El efecto 2038, por el contrario, se sigue extendiendo cada vez que se fabrica una CPU de 32 bits o se programa con el time_t de 32 bits con signo

#4   Y a los entendidos en la materia: ¿Este error es subsanable? ¿Tendría algún efecto notable, al contrario que el efecto 2000?

#2   Esto es el fin ... a todas estas por esos días también nos va a impactar un meteorito ...

#57   ¡ Esta noticia es antigua !
El caos ya lo predijo Jonh Titor ( es.wikipedia.org/wiki/John_Titor ) hace un par de años. De hecho, ese fue su principal motivo para viajar a nuestro tiempo !!!

"Los mensajes que dejó Titor afirman que era un soldado al cual se le asignó la misión de participar en un programa gubernamental de viajes en el tiempo. Supuestamente fue enviado desde 2036 hasta 1975 para conseguir un ordenador IBM 5100. Según él, esta máquina era necesaria para solventar el Efecto 2038, análogo al Efecto 2000, sufrido por los ordenadores con sistema operativo UNIX. "

(Ahora en serio, historia y toda la mitología al rededor de John Titor de verdad no tiene desperdicio ;))

#23   Es la SEÑAL. Una vez llegado ese punto, todo volverá a tal año y así sucesivamente... un ciclo sin fin.

#17   #14 si recordara la tecnología de hace 50 años, cumpliría -29

#37   #36
En ensamblador/lenguaje máquina, hay instrucciones para comparar enteros, lo que ya no sé es si lo que hacen es restar los números o no.
Sí, la circuitería del procesador usa restas para comparar. El ensamblador sigue siendo una abstracción (de las de más bajo nivel, claro)

Lo hagan restando o no, lo que se necesita es un signo para saber cual de los dos enteros que se comparan es el mayor.
Ya, eso es lo que tenemos ahora, aprovechamos el bit de signo del complemento a dos para comparar.

Y para hacer esto, no se necesita que los dos enteros a comparar tengan signo.
Y si restamos peras y manzanas obtenemos plátanos. O podemos restar peras y peras, manzanas y manzanas, plátanos y plátanos...

#16   Excelente informacion. Gracias.

#33   #32 es que soy Einstein, ya sabes

#1   Arreglé el enlace, la ñ no se parseaba correctamente.

#52   pinar, mira #50, que en Linux ya está solucionado desde hace años con la arquitectura de 64 bits...

#22   #21 a Moisés...

#24   Estoy con #21: ¿Por qué narices usan un contador con signo? Se pierde la mitad de segundos representables. Si esto tiene algún motivo, que alguien lo explique.

#18   Es verdad, entonces preguntale a tus ancestros.

#38   joder cuanto cálculo. Por casualidad no estaréis estudiando nada relacionado con la informática?

#42   #37 Y si restamos peras y manzanas obtenemos plátanos. O podemos restar peras y peras, manzanas y manzanas, plátanos y plátanos...

Joder, me recuerdas a Ana Botella...

#44   #40
Pero se puede comparar sin restar, no nos hace falta la diferencia entre los dos, solo cual es mayor. Eso se hace en los lenguajes de alto nivel, en lenguaje máquina o en ensamblador. No hace falta cast ni nada parecido.
Explícale eso a los transistores de silicio de la CPU. Por cierto, que al #24 lo conozco personalmente, de verlo cada día, de ahí mi licencia (y dudo que le haya insultado)

#42 sí, ha sido mi intención

#62   #61 me gustaría saber si he sido yo (Rectificar es de sabios™)

#39   Genial!! El mundo se ira al traste el dia de mi 58 cumpleaños!!

#48   #47 excelente explicación, gracias

#53   Hombre, no creo que se pueda comparar con el efecto 2000 y las soluciones/chapuza de limitar el rango de fechas a un siglo para ir tirandillo, pero vamos, que tratándolo con antelación no será nada grave.

Ains... si es que los informáticos son unos chapuceros... oh, wait!

PD: Venga, alguien que reste cuánto queda para el 1/ene/10000 día del efecto 10.000

#45   Me estais contando que dentro de 31 años,va a pasar exactamente lo mismo que en el 2000?.....osea NADA!!!!! que miedo mas grande tengo yo en el cuerpo...como nos descuidemos,nuestros microndas en vez de calentarnos la leche esa mañana,no la dejan congelada!!!!

#56   gracias #1, jotape

#21 no es una noticia de la Wikipedia, porque la Wikipedia no es un periódico. Tampoco es sobre la Wikipedia, porque no analiza cómo se trata allí esta información. Simplemente la Wikipedia explica bien esta noticia de una efeméride.

Felicidades, #39

#14   JP, solo recuerda como era la tecnología hace 50 años.

#13   #10 sí, Aramil, pero es que ciertos sistemas no requieren 64 bits (ni 32, ni 16). También es cierto que no siguen el estándard POSIX (ni ninguno, suelen ser de su padre y de su madre ), pero usarse se usan.

<opinion> Moore mola, pero para las CPU's de casa y tal, no para los entornos especializados. </opinion>

#34   Que le quiten el signo y ya tenemos otro siglo y pico!!

Los que sepan de qué va el complemento a 2 sabrán que los números positivos y los equivalentes sin signo son iguales en binario.

#21   otra noticia de la wikipedia ?

a quien se le ocurrió usar un contador con signo para implementar esto ?

#35   pues es lo que les debe pasar con el boletín informativo de 20 minutos.es ya que llega con fecha 01/01/1970 1:00

#60   Pero si no va a haber ni ordenadores, ni os preocupeis...

www.crisisenergetica.org/

#3   preparense para las previsiones apocalipticas

#5   Otro fallo 2K!

#59   Voto el comentario anterior para el hoygan del dia...

#36   En ensamblador/lenguaje máquina, hay instrucciones para comparar enteros, lo que ya no sé es si lo que hacen es restar los números o no. Lo hagan restando o no, lo que se necesita es un signo para saber cual de los dos enteros que se comparan es el mayor. Y para hacer esto, no se necesita que los dos enteros a comparar tengan signo.

#10   Pero recuerda el avance tecnólogico, Ley de Moore y demás.

#51   En realidad todo esto pasará si triunfa linux, ya que es un sistema Unix. Si la batalla la gana windows en realidad no tenemos de que preocuparnos. Almenos por esto.

#46   Pasará lo mismo que en el 2000: tropecientos de programas shareware para detectar y corregir el problema en su kiosco .

#54   Que bien, no tengo ningún problema, y aunque ahora tengo un portatil de 64bits, creo que no durara para el 2038

#63   Decidme que aprender todo eso es fácil

#40   Bueno he sido algo exagerado diciendo lo de Einstein, lo reconozco, lo que pasa es que #26 se había metido con #24 y yo he hecho igual, igual que han hecho los demás conmigo.

Estoy de acuerdo en que restando dos enteros sin signo, no se puede comparar fechas pues el resultado de la resta siempre es un entero sin signo.
Pero se puede comparar sin restar, no nos hace falta la diferencia entre los dos, solo cual es mayor. Eso se hace en los lenguajes de alto nivel, en lenguaje máquina o en ensamblador. No hace falta cast ni nada parecido.

#58   Menuda chorrada. Basta con poner un entero sin signo, y automáticamente desaparece el problema durante más de 60 años, hasta el 2106.