Portada
mis comunidades
otras secciones
#13:
Siento amargaros la fiesta, pero es antigua y triplicada:
19 de enero de 2038 a las 03:14:07 el fin del mundo (otra vez)
El efecto 2038
19-01-2007: a 31 años del efecto 2038
19 de enero de 2038 a las 03:14:07 el fin del mundo (otra vez)
Publicado hace 16 años por
tomasulo
a
alejandroherrero.com
El efecto 2038
Publicado hace 18 años por
Carme
a
fentlinux.com
19-01-2007: a 31 años del efecto 2038
Publicado hace 17 años por
benjami
a
es.wikipedia.org
#6:
Algo más sobre el asunto en español... http://es.wikipedia.org/wiki/Problema_del_año_2038
#5 ahora en serio, si de aquí al 2038 no hemos pasado a 64 bits tenemos un problema como civilización
#5 ahora en serio, si de aquí al 2038 no hemos pasado a 64 bits tenemos un problema como civilización
#30:
Me hace gracia que escriban Y2K38 (5 caracteres) frente a 2038 (sólo 4)
#2:
Tu no #1. Pero la cantidad de cacharros que hay por ahi (switches, routers, televisiones, marcos digitales, reproductores de divx, neveras, etc. etc) con un Linux embedded...
"El máximo valor de un entero de 4 bytes es 2,146,483,547"
El valor máximo de un entero CON SIGNO de 32 bits es 2,147,483,647. (2^31 - 1)
"El máximo valor de un entero de 4 bytes es 2,146,483,547"
El valor máximo de un entero CON SIGNO de 32 bits es 2,147,483,647. (2^31 - 1)
Comentarios
Siento amargaros la fiesta, pero es antigua y triplicada:
19 de enero de 2038 a las 03:14:07 el fin del mundo (otra vez)
19 de enero de 2038 a las 03:14:07 el fin del mund...
alejandroherrero.comEl efecto 2038
El efecto 2038
fentlinux.com19-01-2007: a 31 años del efecto 2038
19-01-2007: a 31 años del efecto 2038
es.wikipedia.org#2 esos aparatos YA están programados para durar 2 o 3 años, no me jodas
Me hace gracia que escriban Y2K38 (5 caracteres) frente a 2038 (sólo 4)
Algo más sobre el asunto en español... http://es.wikipedia.org/wiki/Problema_del_año_2038
#5 ahora en serio, si de aquí al 2038 no hemos pasado a 64 bits tenemos un problema como civilización
Tu no #1. Pero la cantidad de cacharros que hay por ahi (switches, routers, televisiones, marcos digitales, reproductores de divx, neveras, etc. etc) con un Linux embedded...
"El máximo valor de un entero de 4 bytes es 2,146,483,547"
El valor máximo de un entero CON SIGNO de 32 bits es 2,147,483,647. (2^31 - 1)
Como que en el 2038 vamos a estar usando todavía sistemas 32-bit
#6 ¿quedan solo 30 años eh?
Tambien hay que migrar a IPv6, a HDTV... no se yo si dará tiempo a tanto cambio.
#1 eso se decía en los años 60, y mira
De todas maneras no me acabo de creer lo que dice la web: o estoy muy equivocado, o las distros actuales almacenan la fecha en 64 bits desde hace bastantes años.
Los problemas se darán con máquinas antiguas o con chips empotrados (a los que es muy difícil actualizar el firmware).
#13 Aguafiestas
#3 cualquier programa corriente y moliente utiliza el tipo de datos "time_t", que en un sistema de 32 bits acaba siendo un int.
Peor aún, muchos programas no utilizan el time_t para almacenar la fecha y lo hacen con int directamente.
Yo utilizo un sistema de 64 bits hoy, a mi me la suda...si quereis probar el efecto, poned la fecha momentaneamente a 31 de diciembre de 2037 a las 11:59. Aquí no he tenido ningún problema, excepto tener que hacer login de nuevo para entrar en meneame, y una expiración de certificado en firefox.
De todas maneras hay que destacar que este no es un problema de Linux, sino del hardware. Los procesadores de 32 bits no pueden incrementar de forma atómica un número mayor de 32 bits, todo lo que se haga para solucionar este problema por software será una chapuza.
También está el problema del año 2070... http://en.wikipedia.org/wiki/Year_2070_problem
Pero para esa fecha, no creo que esté yo por aquí
¿2038?
Bueno, me preocuparé en 2018... si para entonces todavía no hemos vuelto a la edad de piedra después de que se acabe el petróleo.
#13 Ditto...
#19 De aquí a 30 años Vista... será un gigantesco parche...
#10 en realidad pasaría algo más tarde, las 3:14:07 serán el último segundo computable con 32 bits
no es por ser alarmista pero como fabriquen los t-800 usando ubuntu ya sabemos lo que va a pasar
#30 Non comment. Lo único relevante y decente en to la noticia. Un aplauso.
#30 Realmente no es Y2K38 en lugar de 2038. Más bien es Y2K38 en lugar de "Year 2038", y si me apuras, "Year 2038 effect"
El problema del efecto 2038 es muy conocido , sino preguntarle a John Titor : http://es.wikipedia.org/wiki/John_Titor
#10 "De todas maneras hay que destacar que este no es un problema de Linux, sino del hardware. Los procesadores de 32 bits no pueden incrementar de forma atómica un número mayor de 32 bits, todo lo que se haga para solucionar este problema por software será una chapuza."
Mande?
#7 Al HDTV le queda bastante tiempo... con que pasemos a TDT me sentiré satisfecho. Y luego veremos que pasa con el ancho de banda del espectro radioeléctrico como para ver si se podrá pasar a HDTV.
#34 Aquí hablamos de un tema de hardware y el y2k era puro software (1999 > 19100 2000). Se basta por que como dice #2 el máximo valor en UNIXTIME es la fecha del fenomeno Y2K(38)... no se si me explico.
#40 http://en.wikipedia.org/wiki/Time_t
The time_t datatype is a data type in the ISO C library defined for storing system time values. Such values are returned from the standard time() library function. This type is a typedef defined in the standard header. ISO C defines _time_t_ as an arithmetic type, but does not specify any particular type, range, resolution, or encoding for it. Also unspecified are the meanings of arithmetic operations applied to time values.
Unix and POSIX-compliant systems implement the time_t type as a signed integer (typically 32 or 64 bits wide) which represents the number of seconds since the start of the Unix epoch: midnight UTC of January 1, 1970 (not counting leap seconds). Some systems support negative time values, while others do not. 32 bit _time_t_ is deprecated, due to the Year 2038 problem.
Como dice la Wikipedia, los sistemas POSIX suele implementar time_t como un entero con signo.
No hará falta 64 bits para entoces: con quitarle el signo a ese entero de 32 bits ya tenemos el doble de tiempo, hasta 2106.
¡¡Rápido, tenemos que quitarle el signo a un int en todos los sitemas antes de que pasen 30 años!!
#20 ¿Vista? na, para entonces ya habrá salido Tacto... no será tan bonito, pero mucho más políticamente correcto, y sólo con el doble de bugs.
#26 Mientras restes al numero mayor el numero menor, no hay ningún problema incluso aunque no tenga signo. Es más, cuando restas a un numero menor otro mayor, el resultado lo puedes tomar como con signo y seguirás teniendo un resultado válido. El problema vendría cuando restas 2 fechas separadas más de 68 años entre sí (y además restes a la fecha menor la mayor). Pero para entoces seguro que el software está preparado para ello, simplemente con comparar cuál es más reciente es suficiente. Todo esto suponiendo que el anticuado procesador de 32 bits se pasa el carry por el forro.
Yo creo que de aquí a 30 años vista, algún parche sacarán, ¿no?
#40 mírate #2 ...
#10,#12 gogo #0 la fecha no es el 1 de enero, es el 19 de enero...
conocia pero no habia notado el detalle de q muchas cosas no estan corriendo con chips de 64bits. Interesante igualmente ver si dentro de 30 años AUN tenemos chiches a 32bits...
PD: me pregunto q pasara con las hojas viejas de excel en ese entonces?
Por cierto, espero que en el 2038 ya no usemos ninguno de los SOs "con fama" de hoy en día, o mal asunto ;/
Para ese tiempo ya habré comprado un cyborg para el asilo y usará debian venticatorce, así que no hay nada que deba preocuparme.
#44 El problema no es usar enteros con signo o sin signo, sino que los procesadores cuando realizan operaciones los interpretan con signo. Y sobre lo demás que comentas, los procesadores suelen utilizar complemento a dos.
Perdonad, no me había dado cuenta de lo del signo. De todas formas veo un poco absurdo utilizar un entero con signo para almacenar valores que siempre serán positivos, o también se podía haber empezado a contar el primer segundo desde el valor negativo mas bajo posible, incrementando hasta cero y continuando posteriormente con los valores positivos. Esto daría el doble menos uno de valores. O simplemente utilizar solo enteros y empezar desde el 0 hacia delante, que también daría el doble menos uno de valores posibles.
#40 ya lo ha comentado alguno en el hilo.
El tipo de datos time_t que es el que está en "crisis". Este tipo de datos es un typedef de otro tipo de datos entero, esto depende de la biblioteca que se use puede ser uno u otro, con signo y sin signo. Y además el tipo de datos puede tener un tamaño diferente e incluso alineación de bits distinto según la arquitectura.
En C se puede llegar a tener bastante control sobre estas cosas, alienaciones de bits, tamaños de tipos de datos, etc...
El caso es que la peor de las combinaciones sería una definición de time_t como int con signo representado por 4 bytes. Como cometas 4 bytes son 32 bits, pero en el caso de que sea un tipo de datos con signo (no unsigned int) el bit más significativo se emplea para almacenar el signo, de este modo los mayores valores de números en valor absoluto realmente estarían representando cantidades enteras negativas.
si se solucionó el y2k en windows, como no se va a solucionar una similaritud en una comunidad de gente que mejora, investiga y corrige.
#23, esa solución no arregla del todo el problema, porque como la reprentación de los números negativos y de los mayores de 2^(n-1) es la misma, habría que revisar de todas formas todo el software y bios para asegurarse que no habrá problemas.
Además, por un efecto relacionado, si se hace eso las operaciones con fechas (restar dos valores por ejemplo para ver cuanto tiempo pasa de una a otra) puede dar resultados inesperados.
Saludos
Hombre yo creo que los SO de 64 bits para entonces ya estarán a la orden del dia, creo yo.
bueno, por lo menos tienen hasta ese año para enmendar el error, no a toda prisa como con el 2000
Si mi padre, al mes de usar Windows Vista me dijo que le migrara a Ubuntu, ... en el 2038 no vamos a estar rulando con 64 ? ...
Eso es lo que pasa cuando usas C sin tener que usarlo, que tu código es demasiado e innecesariamente dependiente de la arquitectura. De todas formas dentro de 30 años espero que ni se usen ya 32 bits ni se use ya C excepto como un asm portable.
#9 (...) HDTV le queda bastante tiempo... con que pasemos a TDT(...)
Creo que tienes un pequeño lío con esto del cambio a digital... pero bueno tampoco tengo ganas de aclarate nada ahora. Lee si te interesa el asunto. Me voy a dormir que ya es hora y creo que con los comentarios que llevo habré recaudado suficientes negativos para donarlos esta navidad.
4 bytes=32 bits
2^32=4294967296
Es 4.294.967.296 y no es 2.146.483.547 como pone en la noticia.
4294967296 segundos = 71582788,2666 minutos = 1193046,47111 horas = 49710,269629629 dias = 136,1925195 años
1970+136 = 2106
Según mis cálculos fallaría en 2016 y no 2038. O en algo me equivoco o hay algún dato mal en la noticia.
Que ganas de armagedones, cataclismos y ecatombes que tenemos.
Esto es un síndrome holliwodiense, sin duda.
Sería irónico que después de tanto lío los únicos ordenadores que sobreviviesen fuesen los basados en windows, o incluso en Atari, spectrums y de más.
Ya hemos tenido la dosis catastrofista del día en Meneame. Cual será la siguiente? Petroleo? Meteorito? Clima? Enfermedades? Acebes presidente? Se aceptan apuestas
(todas las opciones me dan repelús por igual)
Otro fake como el YK2000? venga ya.
pero no me pongais negativos, que es una broma. Jo! ahora sufro. Como llame a mi primo Chuck os vais a enterar