«El último segundo representable con este formato será a las 03:14:07 UTC del 19 de enero de 2038, cuando el contador llegue a 2147483647. Un segundo después, el contador se desbordará, y saltará al valor -2147483648, que causará el fallo de programas que interpretarán el tiempo como que están en 1901 ó 1970 (dependiendo de la implementación), en vez de 2038.»
#6:
"Usar un entero de 64 bits retrasaría la fecha del problema unos 290 mil millones de años. Para ser más precisos, ocurriría el domingo, 4 de diciembre del año 292 277 026 596 a las 15:30:08 UTC."
ahem ahem friki ahem
#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 = "GMT";
# Set the Time Zone to GMT (Greenwich Mean Time) for date calculations.
for ($clock = 2147483641; $clock < 2147483651; $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?
#47:
Si intentas comparar dos fechas, tienes que restar. Sin embargo, también puedes necesitar conocer la diferencia entre dos fechas para saber si han pasado X segundos desde la primera y actuar en consecuencia. Para esto hay dos opciones:
a) Restar fecha2 - fecha1 y así conocer la diferencia de tiempo
b) Sumar fecha1 + X y comparar con fecha2
Para los que dicen de lo estúpido del signo, imaginen que X es 86400 * 365 * 30 (algo menos de 30 años). Si utilizas el método b desbordarás la variable, y al ser sin signo no habrá forma de detectar el desbordamiento. Sin embargo, si de la suma obtienes un valor negativo significa desbordamiento, y de hecho puedes calcular el valor de este. Quiero decir, que está totalmente justificado utilizar un entero con signo para poder operar con fechas, lo creáis o no. Cosas de que aún sea gratis hablar por hablar.
#7 time_t existe precisamente para eso, para unificar un tipo para las fechas y así poder cambiar la precisión de las fechas sin tener que modificar todos los códigos fuente afectados. Bastaría con recompilar.
#45 El riesgo a día de hoy existe, y es grave. No es ninguna invención malvada de los informáticos para poder exprimirte tu dinero a base de armas silenciosas. Pero aún va a llover mucho y a subir mucho la temperatura global hasta el 2038. Seguramente, para entonces, ya no habrá problemas igual que sucedió con el efecto Y2K. Es lo que tiene tomar como verdad única y absoluta lo que se diga en la TV.
#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)
#29:
#28, cuando se comparan dos números, realmente la máquina los ha de restar. Si la resta es 0 son iguales, por ejemplo.
Otra cosa es que tú uses lenguajes de alto nivel donde eso te lo "esconden" con variables/expresiones booleanas. U otro tipo de datos.
#11:
A los informáticos nos conviene esperar al último momento para arreglarlo. Así se podrá cobrar más pasta.
#15:
#14 Jajajajaja .... #13 Te acaban de llamar VIEJO
"Usar un entero de 64 bits retrasaría la fecha del problema unos 290 mil millones de años. Para ser más precisos, ocurriría el domingo, 4 de diciembre del año 292 277 026 596 a las 15:30:08 UTC."
#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)
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 = "GMT";
# Set the Time Zone to GMT (Greenwich Mean Time) for date calculations.
for ($clock = 2147483641; $clock < 2147483651; $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?
Si intentas comparar dos fechas, tienes que restar. Sin embargo, también puedes necesitar conocer la diferencia entre dos fechas para saber si han pasado X segundos desde la primera y actuar en consecuencia. Para esto hay dos opciones:
a) Restar fecha2 - fecha1 y así conocer la diferencia de tiempo
b) Sumar fecha1 + X y comparar con fecha2
Para los que dicen de lo estúpido del signo, imaginen que X es 86400 * 365 * 30 (algo menos de 30 años). Si utilizas el método b desbordarás la variable, y al ser sin signo no habrá forma de detectar el desbordamiento. Sin embargo, si de la suma obtienes un valor negativo significa desbordamiento, y de hecho puedes calcular el valor de este. Quiero decir, que está totalmente justificado utilizar un entero con signo para poder operar con fechas, lo creáis o no. Cosas de que aún sea gratis hablar por hablar.
#7 time_t existe precisamente para eso, para unificar un tipo para las fechas y así poder cambiar la precisión de las fechas sin tener que modificar todos los códigos fuente afectados. Bastaría con recompilar.
#45 El riesgo a día de hoy existe, y es grave. No es ninguna invención malvada de los informáticos para poder exprimirte tu dinero a base de armas silenciosas. Pero aún va a llover mucho y a subir mucho la temperatura global hasta el 2038. Seguramente, para entonces, ya no habrá problemas igual que sucedió con el efecto Y2K. Es lo que tiene tomar como verdad única y absoluta lo que se diga en la TV.
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.
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.
#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
¡ Esta noticia es antigua !
El caos ya lo predijo Jonh Titor ( http://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 ;))
#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...
#54 Aunque tengas un portátil de 16 bits, podrás estar a salvo del efecto 2038.
#51 Precisamente, debido a que GNU/Linux es un entorno opensource, no tiene el problema que tiene windows: Si tú mantienes tu actual XP hasta el 2038, te darás de bruces con el problema. Y esto ya no es como el efecto Y2K, aquí el propio núcleo está afectado. Sin embargo, en tu distribución de GNU/Linux no tendrás más que actualizar la libc. Un sólo paquetito y time_t saltará de alegría.
Esto... ¿te vuelvo a poner el bozal o prometes ser bueno?
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.
ya #26, pero aun así no hace falta usar un contador con signo. Para algo existen variables enteras auxiliares, cast de tipos, etc. El tema es que el creardor de este estándar de turno no penso mucho en lo que llegaría a ser la informática (a pasado en muchos campos, como interntet, que se desaprovechan muchísimas IPs válidas para tonterías como 127.0.0.1, etc)
#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)
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
#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.
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!!!!
#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.
Moore mola, pero para las CPU's de casa y tal, no para los entornos especializados.
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.
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.
Algún comentarista no entendió la diferencia entre CMP y TEST (y la implementación de las dos es distinta, os lo aseguro). Gallifante para el que señale al culpable. Y no, ensamblador no es un lenguaje de alto nivel que esconda las dificultades de la implementación.
Efectivamente el efecto y2k38 es injustificable y los responsables deberían ser colgados por los testículos.
Si tuviesemos un colegio profesional de informáticos, los responsables de esa cagada no volverían a ejercer nunca jamás
pero #40, el "=" no es mágico, ni el ">=". Los circuitos del procesador tienen que restar, no les queda otra.
EDITO: Sí que hay circuitos que comparan sin restar, he metido la pata. Pero no creo que los procesadores actuales lo hagan así (es muy costoso en tiempo).
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.
#26 eres un Einstein. Sigue sin tener sentido utilizar en este caso un contador con signo. Para ver de dos enteros sin signo cual es el mayor solo hay que compararlos, no hace falta restar. ¿o es que para ver si 988989 y 65656 cual es el mayor los restas primero?
Comentarios
"Usar un entero de 64 bits retrasaría la fecha del problema unos 290 mil millones de años. Para ser más precisos, ocurriría el domingo, 4 de diciembre del año 292 277 026 596 a las 15:30:08 UTC."
ahem ahem friki ahem
A los informáticos nos conviene esperar al último momento para arreglarlo. Así se podrá cobrar más pasta.
yo creo que de aquí al 2038 no existiran CPU's de 32 bit
#14 Jajajajaja .... #13 Te acaban de llamar VIEJO
#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)
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 = "GMT";
# Set the Time Zone to GMT (Greenwich Mean Time) for date calculations.
for ($clock = 2147483641; $clock < 2147483651; $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?
Si intentas comparar dos fechas, tienes que restar. Sin embargo, también puedes necesitar conocer la diferencia entre dos fechas para saber si han pasado X segundos desde la primera y actuar en consecuencia. Para esto hay dos opciones:
a) Restar fecha2 - fecha1 y así conocer la diferencia de tiempo
b) Sumar fecha1 + X y comparar con fecha2
Para los que dicen de lo estúpido del signo, imaginen que X es 86400 * 365 * 30 (algo menos de 30 años). Si utilizas el método b desbordarás la variable, y al ser sin signo no habrá forma de detectar el desbordamiento. Sin embargo, si de la suma obtienes un valor negativo significa desbordamiento, y de hecho puedes calcular el valor de este. Quiero decir, que está totalmente justificado utilizar un entero con signo para poder operar con fechas, lo creáis o no. Cosas de que aún sea gratis hablar por hablar.
#7 time_t existe precisamente para eso, para unificar un tipo para las fechas y así poder cambiar la precisión de las fechas sin tener que modificar todos los códigos fuente afectados. Bastaría con recompilar.
#45 El riesgo a día de hoy existe, y es grave. No es ninguna invención malvada de los informáticos para poder exprimirte tu dinero a base de armas silenciosas. Pero aún va a llover mucho y a subir mucho la temperatura global hasta el 2038. Seguramente, para entonces, ya no habrá problemas igual que sucedió con el efecto Y2K. Es lo que tiene tomar como verdad única y absoluta lo que se diga en la TV.
#28, cuando se comparan dos números, realmente la máquina los ha de restar. Si la resta es 0 son iguales, por ejemplo.
Otra cosa es que tú uses lenguajes de alto nivel donde eso te lo "esconden" con variables/expresiones booleanas. U otro tipo de datos.
yo aspiro a mantener mi equipido hasta ese año ..
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.
Miradlo por el lado bueno, el día que eso suceda, todas las licencias se renovarán automáticamente.
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.
#8 estamos a 2007 y seguimos usándolas de 8 bits...
#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?
#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
Y a los entendidos en la materia: ¿Este error es subsanable? ¿Tendría algún efecto notable, al contrario que el efecto 2000?
Esto es el fin ... a todas estas por esos días también nos va a impactar un meteorito ...
¡ Esta noticia es antigua !
El caos ya lo predijo Jonh Titor ( http://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 ;))
tienes razón #30, yo mismo me he autocontestado en #29 al contestar a #28. jejejeje
Es la SEÑAL. Una vez llegado ese punto, todo volverá a tal año y así sucesivamente... un ciclo sin fin.
#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...
#14 si recordara la tecnología de hace 50 años, cumpliría -29
#54 Aunque tengas un portátil de 16 bits, podrás estar a salvo del efecto 2038.
#51 Precisamente, debido a que GNU/Linux es un entorno opensource, no tiene el problema que tiene windows: Si tú mantienes tu actual XP hasta el 2038, te darás de bruces con el problema. Y esto ya no es como el efecto Y2K, aquí el propio núcleo está afectado. Sin embargo, en tu distribución de GNU/Linux no tendrás más que actualizar la libc. Un sólo paquetito y time_t saltará de alegría.
Esto... ¿te vuelvo a poner el bozal o prometes ser bueno?
Excelente informacion. Gracias.
#32 es que soy Einstein, ya sabes
pinar, mira #50, que en Linux ya está solucionado desde hace años con la arquitectura de 64 bits...
Arreglé el enlace, la ñ no se parseaba correctamente.
Para el 2038 usaremos todos CPUs de 128 bits, ni 64 ni leches
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.
#21 a Moisés...
Es verdad, entonces preguntale a tus ancestros.
#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...
joder cuanto cálculo. Por casualidad no estaréis estudiando nada relacionado con la informática?
ya #26, pero aun así no hace falta usar un contador con signo. Para algo existen variables enteras auxiliares, cast de tipos, etc. El tema es que el creardor de este estándar de turno no penso mucho en lo que llegaría a ser la informática (a pasado en muchos campos, como interntet, que se desaprovechan muchísimas IPs válidas para tonterías como 127.0.0.1, etc)
#61 me gustaría saber si he sido yo (Rectificar es de sabios™)
#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
#47 excelente explicación, gracias
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
Genial!! El mundo se ira al traste el dia de mi 58 cumpleaños!!
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
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!!!!
JP, solo recuerda como era la tecnología hace 50 años.
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.
#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.
Moore mola, pero para las CPU's de casa y tal, no para los entornos especializados.
otra noticia de la wikipedia ?
a quien se le ocurrió usar un contador con signo para implementar esto ?
#48 de nada sir jotape
#38 nooooooooooooooo que va
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
Pero si no va a haber ni ordenadores, ni os preocupeis...
http://www.crisisenergetica.org/
Otro fallo 2K!
Voto el comentario anterior para el hoygan del dia...
preparense para las previsiones apocalipticas
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.
Pero recuerda el avance tecnólogico, Ley de Moore y demás.
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.
Algún comentarista no entendió la diferencia entre CMP y TEST (y la implementación de las dos es distinta, os lo aseguro). Gallifante para el que señale al culpable. Y no, ensamblador no es un lenguaje de alto nivel que esconda las dificultades de la implementación.
Efectivamente el efecto y2k38 es injustificable y los responsables deberían ser colgados por los testículos.
Si tuviesemos un colegio profesional de informáticos, los responsables de esa cagada no volverían a ejercer nunca jamás
Pasará lo mismo que en el 2000: tropecientos de programas shareware para detectar y corregir el problema en su kiosco .
Que bien, no tengo ningún problema, y aunque ahora tengo un portatil de 64bits, creo que no durara para el 2038
pero #40, el "=" no es mágico, ni el ">=". Los circuitos del procesador tienen que restar, no les queda otra.
EDITO: Sí que hay circuitos que comparan sin restar, he metido la pata. Pero no creo que los procesadores actuales lo hagan así (es muy costoso en tiempo).
Decidme que aprender todo eso es fácil
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.
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.
#26 eres un Einstein. Sigue sin tener sentido utilizar en este caso un contador con signo. Para ver de dos enteros sin signo cual es el mayor solo hay que compararlos, no hace falta restar. ¿o es que para ver si 988989 y 65656 cual es el mayor los restas primero?