El efecto 2038

¿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! [carcajad] 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 [Ooooo]). Apple puede presumir de representar fechas en Mac OS hasta... ¡29.940! :O
Lo dije jajajjaa lo diiijeeee, pero no me creyeron!!! jajjaja, pensaban que estaba looco, pero no estaba loco cuando les dije "en el 2038 se acabará el mundo mundial (y parte del extranjero).

Recordad... 2038... Nostrurouni lo dijo... escribiré mi libro "Las buenas y aproximadas profecías de Rurouni".

P.D: en el 2006 del día 26 de Febrero (que es domingo por la mañana) nos invadirán los estraterrestres venidos de ZX-80, un planeta en el que solo hay desiertos y casinos.
¿Alguien tiene un athlon 64 para probarlo en un Linux de 64 bits?

PD:
Rurouni ¿Te has tomado la medicación?
Juas [qmparto] menos mal que hay tiempo para solucionarlo. Y con los aparatos con procesador de 32 bits con mini sistema UNIX... pos se compra otro :Ð (de aqui mas de 30 años seguro que esta desfasado).

Rurouni escribió:P.D: en el 2006 del día 26 de Febrero (que es domingo por la mañana) nos invadirán los estraterrestres venidos de ZX-80, un planeta en el que solo hay desiertos y casinos.


[qmparto] [qmparto] Al dia 26 espero verte en la tele [fumeta] [qmparto]
Harl escribió:¿Alguien tiene un athlon 64 para probarlo en un Linux de 64 bits?


Yo no, pero sí tengo la página info de date:

Although the date syntax here can represent any possible time since
the year zero, computer integers often cannot represent such a wide
range of time. On POSIX systems, the clock starts at 1970-01-01
00:00:00 UTC: POSIX does not require support for times before the POSIX
Epoch and times far in the future. Traditional Unix systems have
32-bit signed `time_t' and can represent times from 1901-12-13 20:45:52
through 2038-01-19 03:14:07 UTC. Systems with 64-bit signed `time_t'
can represent all the times in the known lifetime of the universe.

Supongo que para enero de 2038, ya usaré un sistema operativo com un time_t de 64 bits... ;-)
T___Tx muchas noches sin dormir... muchas...

Supongo que para enero de 2038, ya habré podido comprarme un orndeador de 64 bits...
Y yo un monopatín volador... que creo que falta un año para ellos segun Regreso al Futuro 2.

P.D: el 10 de Marzo del 2007 le tocará la lotería a Paquito Sifuentes Garciá, Matalascañas (California), enhorabuena a los premiados.
Humm... y digo yo, por que no se utiliza otro sistema independiente de la fecha de inicio?

Es decir, si ahora tenemos un timestamp de 923405860, pues en el aparato ponemos q vaya contando desde 0 , y la fecha real seria n + 923405860. Y que cuando llegase al final de los 32 bits, pues almacenase el numerito y volviese a empezar, del estilo fecha real: n+ ultimo timestamp posible..... no se si se me entiende...

tampoco tengo mucha idea sobre programacion, eh...
el asunto necesita un "parche", igual que el mas cantoso de asumir el "19" delante que hubo el siglo pasado :-P

habra sistemas que se podran actualizar, y habra sistemas que directamente habra que tirar al rio.

Por cierto, yo esto lo se desde el 2º dia que me dieron clases de linux en el ciclo (viene en el man del date si no recuerdo mal).

supongo que no se podran a solucionarlo hasta el 2036 mas o menos.

saludos cordiales.
GXY escribió:supongo que no se podran a solucionarlo hasta el 2036 mas o menos.

saludos cordiales.



john titor decia venir del 2036 a por un trasto de IBM del año catapum, por que podia leer no se que codigos escritos en ensamblador........ asi que ahi teneis la evidencia de que no lo arreglan hasta el 2036 XD
Apple puede presumir de representar fechas en Mac OS hasta... ¡29.940!


No será en OSX... quizá será en System9, en OSX tiene la mismísima limitación que tienen los demás :D (recuerda que darwin = freebsd + mach + altivec )

Salu2.Ferdy
Rurouni escribió:Lo dije jajajjaa lo diiijeeee, pero no me creyeron!!! jajjaja, pensaban que estaba looco, pero no estaba loco cuando les dije "en el 2038 se acabará el mundo mundial (y parte del extranjero).

Recordad... 2038... Nostrurouni lo dijo... escribiré mi libro "Las buenas y aproximadas profecías de Rurouni".

P.D: en el 2006 del día 26 de Febrero (que es domingo por la mañana) nos invadirán los estraterrestres venidos de ZX-80, un planeta en el que solo hay desiertos y casinos.


Pues me da que la profecía no ha resultado del todo cierta... no he visto extraterrestres del planeta ZX-80, eso si, he visto uno del planeta Pendejus Analogicus [sati]

Saludos ;)

Pd. Perdón por reflotar el hilo, pero lo he visto y no he podido contenerme [+risas] [+risas]
XD

Y el bug sigue ahi, sin solucionar...

Adjuntos

Pringaos...

franjva@tay64 ~ $ perl testtime.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


XD
En Gentoo para amd64 todo correcto, ¡yo sobreviviré!
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
Agur
En MacOSX también funciona:
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:07 2038
Tue Jan 19 03:14:07 2038
Tue Jan 19 03:14:07 2038


(¿ O soy un perro y os he hecho un copy&paste? xDD. No, sí que funciona)

Un saludo.
Fedora core 4

[sl1pkn07@SpinFlo ~]$ ./2038.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
[sl1pkn07@SpinFlo ~]$
jPlayer escribió:Pues me da que la profecía no ha resultado del todo cierta... no he visto extraterrestres del planeta ZX-80, eso si, he visto uno del planeta Pendejus Analogicus [sati]
Están entre nosotros... de incógnito. Llevan gorras con la visera hacia atrás, ropa deportiva de colores vivos, cadenas de oro y anillos en todos los dedos... además de cantar rap. Vamos, 100% integrados en la sociedad española.

Anda que... está reflotando cada hilo últimamente :D

Saludillos!
bastian escribió:En MacOSX también funciona:
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:07 2038
Tue Jan 19 03:14:07 2038
Tue Jan 19 03:14:07 2038

(¿ O soy un perro y os he hecho un copy&paste? xDD. No, sí que funciona)

Un saludo.

Si te fijas bien no funciona, ya que en vez de volver a 1901 sigue en 2038, pero en el mismo segundo, el limite: 03:14:07

Agur
y para los que no lo tienen solucionado, que hay que parchear?
Zamorate escribió:Si te fijas bien no funciona, ya que en vez de volver a 1901 sigue en 2038, pero en el mismo segundo, el limite: 03:14:07

Cierto, no me había fijado :D. Vaya, parece que el portátil tiene fecha de caducidad. Tendré que jubilarlo y comprarme otro cuando caduque. :P
Rurouni escribió:Están entre nosotros... de incógnito. Llevan gorras con la visera hacia atrás, ropa deportiva de colores vivos, cadenas de oro y anillos en todos los dedos... además de cantar rap. Vamos, 100% integrados en la sociedad española.


Qué cruel. [qmparto]

Aunque algunos compañeros ya lo han posteado, ni que sea para re-que-te-confirmar que en AMD64 el problema no existe.

paco@gentoo64 ~/Desktop/Documentos $ ./2038
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


Saludos.
capzo escribió:y para los que no lo tienen solucionado, que hay que parchear?


misma pregunta
kubuntu Dapper

./timestamp.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

Creo que voy a enviar un bug report a los de Ubuntu a ver que me dicen.
Txukie escribió:Creo que voy a enviar un bug report a los de Ubuntu a ver que me dicen.


Que, o bien conseguimos pronto una alianza de civilizaciones, o no hay que preocuparse por la fecha de los ordenadores ya que no vamos a llegar a 2038.
Txukie escribió:kubuntu Dapper

./timestamp.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

Creo que voy a enviar un bug report a los de Ubuntu a ver que me dicen.


juas juas juas, pues si consiguesalguna respuesta posteala xD.
Por cierto, yo sigo pensando que el efecto 2000 no existió. Un familiar mio trabajó en una empresa que se dedicó a preparar sistemas informáticos de bancos, etc. para el dichoso bug. Y la última vez que le pregunté me dijo que era un camelo...

Alguien puesto en el tema que lo confirme?¿

Saludos!!
Yo te confirmo que sí existe, mi padre usaba para su empresa un programa de gestión, que aparte de mostrar mal en pantalla las fechas de los archivos, da segfault al intentar guardarlos ;)

Lo que es un camelo lo que vi hace tiempo en un centro de salud de aquí: Una TV de hace más de 10 años (con sintonizador de rueda XD), con la pegatina de haber pasado el test de efecto 2000.

La de pasta que se sacaron algunos listos esos años XD
Y para qué arreglarlo? Si hay que volver al siglo XX pues se vuelve y listo. Total, ya hemos sufrido la decepción de llegar al siglo XXI y ver que ni somos más espaciales ni llevamos trajes plateados ni na.

Además pensad en las ventajas: todas las patentes quedarían invalidadas y habría via libre para la innovación [oki]
ya tengo ganas de que llegue el 38 para ver q pasa
juas juas juas, pues si consiguesalguna respuesta posteala xD.


Me he perdido algo? Que es tan gracioso? Acaso no es un bug?
capisergio@Cyberbrain ~ $ uname -a && perl ./fecha.pl 
Linux Cyberbrain 2.6.15-gentoo-r7 #2 SMP Mon Mar 13 22:19:29 CET 2006 x86_64 AMD Athlon(tm) 64 X2 Dual Core Processor 4200+ AuthenticAMD GNU/Linux
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


Tos muertos en el 2038 xDD
Txukie escribió:

Me he perdido algo? Que es tan gracioso? Acaso no es un bug?


Pues me resulta gracioso porque es un bug clásico de los sistemas Unix y no creo que lo hayan considerado un bug, o también porque no creo que se le haya ocurrido a mucha gente. De todas maneras lo de que postees la respuesta iba en serio. Si te reponden algo tengo mucha curiosidad por saber lo que te dicen.

Saludos!!!
A mi me llega un bug así, y RESOLVED->DONTWASTEMYTIMEOKTHANKSBYE
K bueno el hilo. XD
Para el 2038, dentro de 22 años, esto no debería ser mas que una anécdota teniendo en cuenta el ritmo al que va la informática.
Por otro lado, a mí lo que me dijeron es que según la ley de alguien (Moore?), el silicio no da mucho más de sí. Con medias palabras fijo que estoy metiendo mucho la gamba pero la idea es algo así como que quedan como unos 10-15 años de esta era de silicio. Había algún reportaje por algún lao sobre qué se estaba estudiando pero sonaba un poco a ciencia ficción y tal...

Además, como dice alguien en gnu/linux para x86_64 está ya corregido :p

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


Un saludo [beer]
Además, como dice alguien en gnu/linux para x86_64 está ya corregido


Antes lo estuvo en Alpha, y sea como fuere, es porque un entero en esas arquitecturas ocupa 8 bytes :)

Saludos.Ferdy
En PowerPC de 32 bits tambien está resuelto:

jaime@crystal /tmp $ uname -a && ./reloj
Linux crystal 2.6.15-gentoo-r1 #1 PREEMPT Fri Feb 10 08:47:46 CET 2006 ppc 7447A, altivec supported PowerMac10,1 GNU/Linux
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:07 2038
Tue Jan 19 03:14:07 2038
Tue Jan 19 03:14:07 2038


De aqui a 2038 la informatica seguro que se parece a la de ahora como un huevo a una castaña.
salmon, no lo tienes resuelto, se queda pillado en el mismo segundo..
f5inet escribió:salmon, no lo tienes resuelto, se queda pillado en el mismo segundo..


XDD que cagada...

dreamer escribió:Por otro lado, a mí lo que me dijeron es que según la ley de alguien (Moore?), el silicio no da mucho más de sí. Con medias palabras fijo que estoy metiendo mucho la gamba pero la idea es algo así como que quedan como unos 10-15 años de esta era de silicio. Había algún reportaje por algún lao sobre qué se estaba estudiando pero sonaba un poco a ciencia ficción y tal...

Tienes razón, estás metiendo la gamba. :P
La Ley de Moore viene a decir precisamente lo contrario, más o menos que cada año un transistor ocupa la mitad (y por tanto puedes meter el doble en un chip del mismo tamaño) pero sí, está claro que no siempre se va a poder cumplir. Y el hecho de que no sea tan fácil reducirlos de tamaño, hace que no puedas subir la frecuencia indefinidamente, porque las longitudes de onda se hacen comparables al tamaño del circuito y te pasas al campo de las microondas. Lo que me partía el culo hace un añito o dos cuando la gente hablaba de micros de 20,30 o 50GHz. Ahora ya no lo dicen tanto, será porque en un año apenas ha avanzado la cosa. Y por eso han tenido que salir con otras artimañas, como HT, procesadores de doble núcleo,etc.

PD: Perdón por el rollo, sé que no venía a cuento.

Un saludo.
Entonces ese bug no afecta a las CPU's Alpha y de 64bits pero al resto de 32bits si???
Capzo
Entonces ese bug no afecta a las CPU's Alpha y de 64bits pero al resto de 32bits si???


No afecta a los SO preparados para las cpu 64 bits pero sí a los de 32 bits
capzo escribió:Entonces ese bug no afecta a las CPU's Alpha y de 64bits pero al resto de 32bits si???


la cosa debe ser mas bien, que como el problema esta que se representa el timestamp como un entero de 32 bits, todo SO que sea de 32 bits, tendra ese problema... (Claro esta, que tome la fecha de inicio como el timestamp UNIX, sino, pues simplemente sera en otro año).
Y claro, en un SO de 64 bits, pues la cosa no es que lo hayan arreglado, sino que el problema queda postergado para unos cuantos (muchisimos) años mas. No es por que las CPU's de 64 bits no tengan el problema, sino que obviamente, esas cpu's de 64 bits estan corriendo SO de 64 bits, que como decia no tienen ese problema ese año.
keo01 escribió:
la cosa debe ser mas bien, que como el problema esta que se representa el timestamp como un entero de 32 bits, todo SO que sea de 32 bits, tendra ese problema... (Claro esta, que tome la fecha de inicio como el timestamp UNIX, sino, pues simplemente sera en otro año).
Y claro, en un SO de 64 bits, pues la cosa no es que lo hayan arreglado, sino que el problema queda postergado para unos cuantos (muchisimos) años mas. No es por que las CPU's de 64 bits no tengan el problema, sino que obviamente, esas cpu's de 64 bits estan corriendo SO de 64 bits, que como decia no tienen ese problema ese año.


Hombre, sí, en realidad sólo se ha alargado, pero es que se ha alargado de 68 a 292.471.208.677 años, así que yo no veo un gran problema... [+risas]

Saludos.
Me he columpiao bastante [ayay]. Lo curioso es q es un error diferente al de la maquina de Khosu. Parece que en x86 el reloj comienza de 0 mientras que en ppc se queda parado en la fecha final.

¿La solucion no sería poner un contador del nº de veces que ha expirado el contador (en 32 bits, sería el periodo 1970 a 2038, etc.)? Supongo que en Alpha lo habrán solucionado así, no?
De aquí a 32 años no se sabe ni existiremos, como para pensar en sacrificar rendimiento actualizando otro registro :P

Aparte que dudo bastante que sigamos con CPUs de 32 bits.
el_Salmon escribió:Me he columpiao bastante [ayay]. Lo curioso es q es un error diferente al de la maquina de Khosu. Parece que en x86 el reloj comienza de 0 mientras que en ppc se queda parado en la fecha final.

¿La solucion no sería poner un contador del nº de veces que ha expirado el contador (en 32 bits, sería el periodo 1970 a 2038, etc.)? Supongo que en Alpha lo habrán solucionado así, no?

Los alpha son de 64 bits.

Agur
Churly escribió:De aquí a 32 años no se sabe ni existiremos, como para pensar en sacrificar rendimiento actualizando otro registro :p

Aparte que dudo bastante que sigamos con CPUs de 32 bits.
Y de 64 bits, al ritmo que va la informatica...
Un apunte, la noticia fue publicada en barrapunto en 2004 por Pobrecito Hablador [toctoc]


http://barrapunto.com/articles/04/08/22/0053214.shtml
Churly escribió:De aquí a 32 años no se sabe ni existiremos, como para pensar en sacrificar rendimiento actualizando otro registro :P

Aparte que dudo bastante que sigamos con CPUs de 32 bits.


Eso debieron pensar en 1980 con el efecto 2000
(que por cierto al final no paso nada)

Por cierto lo probe en mi A64 y creo que va bien X-D
Hombre, no exactamente lo mismo :P Por aquella época cualquiera desperdiciaba un bit de más con lo cara que era la RAM.

Pero ya se sabe, 640kB deberían ser suficientes para cualquiera [666]
52 respuestas
1, 2