Historias
Slashboxes
Comentarios
Búsqueda

"timestamp": efecto 2038

editada por Yonderboy el 22 de Agosto 2004, 00:28h   Printer-friendly   Email story
desde el dept. Y2K38
Bug (errata)
pobrecito hablador nos cuenta: «¿Os acordáis del efecto 2000 (Y2K)? Pues el siguiente podría ser el efecto 2038 (Y2K38)... Me explico: Unix Time Stamp (también conocido como Unix Epoch) es el número de segundos transcurridos desde las 0:00:00 del 1 de enero de 1970 GMT. Pues en máquinas de 32 bits, usando complemento a dos, como usamos un bit para el signo, nos quedan 31 bits para la magnitud, y podemos trabajar con números entre el rango [-2^31+1, 2^31-1]. Pues bien, 2^31-1 segundos después del 1 de enero de 1970 a las 0:00:00 GMT, es el 19 de enero de 2038 a las 03:14:07 (que por cierto cae en martes) sería la fecha máxima que podríamos representar y, un segundo después, 03:14:08, se produciría un desbordamiento ("overflow"), lo que podría producir errores en el software que corra sobre dicha máquina...» Continúa.
«Y dado que "timestamp" es un formato de representación de fecha/hora muy frecuente no solo en sistemas Unix, sino también en el lenguajes como C y PHP , en SQL es un tipo de datos, servidores IRC te devuelven la fecha en la que fue modificado por ultima vez el topic de un canal, y supongo que tendrá más aplicaciones.

Estaréis pensando que para el 2038 todos tendremos procesadores de 64 bits por lo menos, pero nuestros móviles (que también podrían usar timestamp) ¿también tendrán más de 32 bits? Dentro de unos años podrán aparecer aparatos electrónicos (relojes, despertadores, vídeos...) que puedan estar basados en timestamp y que dejarían de funcionar a partir de enero del 2038. ¿Debemos preocuparnos? ¿Nos afectará? ¿Se inventará otro formato para representar fechas? De todos modos aun quedan 34 largos años... Podéis ver un pequeño script en perl que chequea el problema en distintos sistemas operativos.»

El script imprime la hora en calendario gregoriano justo unos segundos antes y después de la fecha crítica... Mi máquina --Debian con kernel Linux 2.6.7-- tiene el bug Y2K38... :-(

miquel@kusanagi:~/software$ ./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
miquel@kusanagi:~/software$

Suerte que para entonces ya estaré jubilado y/o tendré un ordenador cuántico. ;-)

Historias relacionadas

[+] El "Y2K" del 19 de enero (y las hipotecas) 42 comentarios
Desde que se mencionó en barrapunto hace cuatro años, el efecto 2038 ya se ha cobrado su primera víctima: el AOLwebserver, que en el 2006 presuntamente golpeó un tope de cálculo futuro. Según el The Project 2038 Frequently Asked Questions (FAQ) ,el próximo dia 19 le podría tocar el turno a alguna calculadora cutre de imprimir hipotecas a 30 años.
Este hilo ha sido archivado. No pueden publicarse nuevos comentarios.
"timestamp": efecto 2038 | Log in/Crear cuenta | Top | 141 comentarios | Buscar hilo
Mostrar opciones Umbral:
Y recuerda: Los comentarios que siguen pertenecen a las personas que los han enviado. No somos responsables de los mismos.

  • salvense quien pueda

    (Puntos:1)
    por pussylover (8089) el Domingo, 22 Agosto de 2004, 00:59h (#340690)
    ( http://www.flickr.com/photos/alexmilla/ )
    Pos eso, los niños y las mujeres primero. xD

    Supongo que una vez descubierto el problema será rápidamente solventado y no se esperará como el efecto 2K hasta el último momento. Aún así el efecto 2K no afecto más que a un par de sistemas importantes como mucho. Mi tostadora todavia no me ha atacado.

  • Entonces...

    (Puntos:1)
    por DrPsi (5293) <konimakiQUITAESTO@gmail.com> el Domingo, 22 Agosto de 2004, 00:59h (#340691)
    ( http://konimaki.blogspot.com/ )
    ¿El OUTS (Overflow Unix Time Stamp) afectaría principalmente a sistemas basados en unix?¿Y que hay de otros sistemas?
    --

    "Lo único que sé, es que no sé absolutamente nada"

  • por que desde 1970?

    (Puntos:2, Divertido)
    por keo01 (10680) el Domingo, 22 Agosto de 2004, 01:22h (#340692)
    eso mismo me preguntaba yo cuando el otro dia mirando no se que de php( o mysql ) vi que un campo "date" aguantaba desde el 1 de enero de 1970 al 19 de febrero de 2038. Es mas, por que la fecha inicial es 1970? cuando gran cantidad de aplicaciones y productos son bastante posteriores a esa fecha, por que no se coge una fecha cercana a la publicacion del producto (por ejemplo, un movil actual, pos por ejemplo 1 de enero de 2002, o de 2004)?¿?

    Ya me veo a los que empezaron esto, en el momento de decidir usar este sistema....

    (alla por 1970...)
    -oye, al final, que hacemos con el problema de la fecha?
    -Tu metele ese sitema que petaba en 2038, que ahora vamos pillaos y no tenemos tiempo de entretenernos con pegiguerias, que tenemos que entregar el proyecto la semana que viene...
    -ya, pero, esto es una chapuza muy grande...
    -tranquilo, ya lo solucionaremos en la proxima version...

    XD

  • Mas información

    (Puntos:3, Informativo)
    por keo01 (10680) el Domingo, 22 Agosto de 2004, 01:31h (#340694)
    En esta web podeis leer un poco mas sobre el tema, eso si, en perfecto inglés:
    http://khatri-krishna.tripod.com/y2k38.htm

    curioso el parrafo final:

    ----
      An alert reader was kind enough to point out that IBM PC hardware suffers from the Year 2116 problem. For a PC, the beginning of time starts at January 1, 1980 and increments by seconds in an unsigned 32-bit integer in a manner similar to UNIX time. By 2116 the integer overflows. Windows NT uses a 64-bit integer to track time. However, it uses 100 nanoseconds as its increment and the beginning of time is January 1, 1601, so NT suffers from the Year 2184 problem. However Apple Computers states that the Mac is OK out to the year 29,940!

    ----
    viene a decir que los pc's(ibm?) tienen la fecha inicial en 1980, y petarán en 2116, mientras que windows NT petara en 2184 , pero que su fecha de inicio es 1601, no se que utilidad puede tener esto...
    Finalmente, se ve que los apple pueden petar en el año 29.940...

  • Otros sistemas operativos

    (Puntos:1)
    por nnss (11726) <reversethis-{moc ... {cemolap.saitam}> el Domingo, 22 Agosto de 2004, 02:04h (#340698)
    ( http://programado.org/ )

    Mientras leía esta noticia recordé haber leído lo mismo hace no mucho. Cuando estaba buscando algún sistema operativo interesante para probar me topé con uno de nombre muy extraño: Unununium [unununium.org] (al menos extraño para mí).

    Ellos justamente conocían este problema y así crearon el Unununium Time [unununium.org]. En sintesis lo que dicen es que guardan la fecha en 64 bits, y esperan que cuando se queden sin espacio para guardar la fecha tengan más ideas de como guardarla.

  • Waaaaa

    (Puntos:2)
    por afterburner (13197) <reversethis-{moc ... {noitsubmoctsop}> el Domingo, 22 Agosto de 2004, 04:41h (#340713)
    ( http://postcombustion.blogspot.com/ | Última bitácora: Sábado, 15 Enero de 2005, 15:47h )
    En el 2038 estaré más tieso que una mojama [elancla.com] así que le den por saco al bug ;) ;) ;) ;)
    --


    --------
    In fire we trust [blogspot.com]
    --------

  • ENTONCES JOHN TITOR TENÍA RAZON

    (Puntos:2, Divertido)
    por pobrecito hablador el Domingo, 22 Agosto de 2004, 05:37h (#340714)
    esto cada vez me da mas escalofrios... John Titor vino del año 2036 por un ordenador IBM por ese "ese pequeño problemilla" del 2038.... para mas informacion pueden "goglear" con las palabras john titor o en http://www.johntitor.com

  • Pues a mi este si me da miedo

    (Puntos:1)
    por motion (10148) el Domingo, 22 Agosto de 2004, 07:49h (#340727)
    ( http://www.callemayor.info/ | Última bitácora: Martes, 06 Noviembre de 2007, 07:59h )
    Efectivamente, y como ya han dicho, este problema afectará a los sistemas que hayan utilizado un 'signed int' para almacenar el tiempo, y se librarán aquellos que hayan utilizado un 'unsigned int' al menos durante otros 68 años más.

        Pero a diferencia del 'Y2K', que era un efecto a nivel 'humano', que afectaba principalmente a bases de datos donde se había querido ahorrar espacio, el efecto '2038' afecta directamente a los sistemas.

        Hay infinidad de aparatos que utilizan el Unix Epoch para simplemente llevar el contador de tiempo del sistema.

        Sin pensar demasiado se me ocurren unas cuantas situaciones en las que los sistemas fallen (sleeps y cualquier comprobación del tiempo). Algunos sistemas podrán salvar el escollo símplemente con ser reseteados (me refiero a los que no tengan que decirle a nadie la fecha que es, y que no utilicen ninguna fecha estática de referencia). Otros no.

        Algo parecido les pasó ya a los aparatos de GPS [space.com] hace unos años .

        -

  • Y ke pasa con el kernel de unix en 64 bits?

    (Puntos:1)
    por condemorerror (15256) el Domingo, 22 Agosto de 2004, 08:08h (#340729)
    Eske el kernel de GNU/linux de 64 bits no tiene estas instrucciones en 64 bits? con lo simple que es de especificar un 'float' en C (64 bit's).

  • El tiempo segun Dr Dan Bearstein

    (Puntos:1)
    por linuxx2 (12587) <linuxx arroba gulic point com> el Domingo, 22 Agosto de 2004, 10:10h (#340752)
    ( http://barrapunto.com/ | Última bitácora: Martes, 10 Febrero de 2004, 11:01h )
    El Sr bearstein ya se dio cuenta hace algunos años de dicho problema e ideo una sistema de conteo del tiempo bastante eficaz que por ahora ha tenido poca resonancia. Para los que no lo sepan Bearstein es el autor entre otras cosas de qmail , djbdns , etc . En su web esta el vinculo al problema del tiempo.
    --

    SysAdmin and BOFH .

    28 December 1969 the BEGIN of the new World.

  • Direccion exacta de la web de Bearstein y el time

    (Puntos:1)
    por linuxx2 (12587) <linuxx arroba gulic point com> el Domingo, 22 Agosto de 2004, 10:15h (#340755)
    ( http://barrapunto.com/ | Última bitácora: Martes, 10 Febrero de 2004, 11:01h )
    http://cr.yp.to/y2k.html El protocolo en cuestion ideado por el Dc es llamado Taiclock. Venga programadores a implementarlo antes del 2038 . XDDD
    --

    SysAdmin and BOFH .

    28 December 1969 the BEGIN of the new World.

  • ¬_¬

    (Puntos:1)
    por DonkeyMCP (9879) <{miguelmcp} {at} {iespana.es}> el Domingo, 22 Agosto de 2004, 10:25h (#340758)
    ( http://donkeyg5.com/ | Última bitácora: Lunes, 11 Febrero de 2008, 17:10h )
    Last login: Sun Aug 22 12:12:24 on ttyp1
    Welcome to Darwin!
    Mac:~ Donkey$ ./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
    Tue Jan 19 03:14:07 2038
    Tue Jan 19 03:14:07 2038
    Tue Jan 19 03:14:07 2038
    Mac:~ Donkey$

    De hecho, el panel de Fecha y hora no me deja poner una fecha más allá del 2007...

    Bueno, que más da, para antes del 2037 es probable que hayan tirado el código de Mac OS X y creen otro totalmente distinto, como paso con Mac OS 9.
    --
    Linux doesn't need no viruses. The users **** up the system by themselves.

  • Complemento a dos

    (Puntos:1)
    por DaGo (8936) el Domingo, 22 Agosto de 2004, 10:53h (#340762)
    ( http://ieeesb.fdi.ucm.es/~david/ )
    "Pues en máquinas de 32 bits, usando complemento a dos, como usamos un bit para el signo, nos quedan 31 bits para la magnitud, y podemos trabajar con números entre el rango [-2^31+1, 2^31-1]."

    El rango del complemento a dos [wikipedia.org] es de [-2^n, 2^n-1]. Hay una única representación para el cero, por lo que no puede ser simétrico.

  • Postresql ha retrasado el problema...

    (Puntos:2)
    por LPR (1796) el Domingo, 22 Agosto de 2004, 11:01h (#340766)
    ( http://barrapunto.com/ | Última bitácora: Domingo, 11 Noviembre de 2007, 15:32h )
    ... hasta el año 5874897.

    Esperemos que para entonces podamos almacenar fechas posteriores.
    --

    --
    Linux is no longer a philosophy- it is a good piece of software. Use it if it fits your needs.

  • Esto se arregla solo :)

    (Puntos:1)
    por polakillo (4986) el Domingo, 22 Agosto de 2004, 12:21h (#340789)
    ( http://www.polakilandia.org/ )
    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


    Linux home 2.6.7 #1 Tue Aug 3 09:19:06 EDT 2004 x86_64 x86_64 x86_64 GNU/Linux

    De lo que deduzco que tanto el kernel, como un herramineta común como puede ser el perl, funcionan perfectamente si el tamaño de palabra de la máquina es de 64 bits.

    La pregunta sería, cuantas máquinas de 32 bits funcionarán dentro de 34 años??

    Desde mi punto de vista y observando la evolución de los últimos 10-15 años, diría que el número de máquinas que se podrían ver afectadas dentro de 34 años tiende a 0.
    --
    "Lo único que MS fabricará que no se quede colgado será una percha"

  • No hay ningún problema... para unix.

    (Puntos:2)
    por quk (8884) el Domingo, 22 Agosto de 2004, 12:59h (#340799)
    ( http://barrapunto.com/ | Última bitácora: Martes, 25 Marzo de 2008, 00:48h )
    Simplemente se recompilarán el kernel y las aplicaciones con el nuevo tamaño del time_t, y ya está. De hecho, ya hay algunas versiones de unix de 64 bits donde el time_t no son 32 bits. Para unix esto no es ningún problema, porque el tamaño del tipo está encapsulado.

    El problema estaría con Windows, porque allí no es recompilar y listo. Los programas Windows suelen hacer suposiciones acerca del tamaño concreto de las cosas, y su compatibilidad binaria depende de ello.

    No obstante, tampoco va a ser ningún problema para Windows, ya que por esas fechas habrá desaparecido, y Microsoft será simplemente un venderdor de MSLinux, distribución que por cierto se caracterizará por su inestabilidad y elevado tiempo de arranque.

  • Una solución bastante buena

    (Puntos:2)
    por DanielSan (10124) el Domingo, 22 Agosto de 2004, 15:21h (#340866)
    ( http://www.guslibu.org/ | Última bitácora: Martes, 22 Enero de 2008, 17:39h )
    Qué tal si guardamos las fechas en formato aaaammddhhss?

    Se necesitan 12 bytes, que son exactamente 8x12=96 bits (en comparación con los 64 bits que piden los PC para superar el problema), pero mirad, aguantará hasta el año 10.000 y permite codificar fechas anteriores a 1970, lo cual es una aproximación bastante buena, y te olvidas de problemas. Y en entornos que necesiten ahorrar espacio, también podría codificarse esa cadena usando 4 bits para cada dígito (usando sólo del 0000 al 1001), con lo que cada fecha se podría codificar fácilmente en sólo 6 bytes (8x6=48bits). Por ejemplo.

    Tengo que decir en defensa del editor del artículo que yo SI he entendido que el problema no afectará seguramente a los ordenadores, sino a multitud de dispositivos de menos potencia en los que se ejecutará código escrito para computadoras.

  • Rayos! WinMe tambien lo tiene....

    (Puntos:1)
    por tomman (13087) el Domingo, 22 Agosto de 2004, 16:10h (#340887)
    ( http://t38.webhop.biz/ | Última bitácora: Domingo, 17 Febrero de 2008, 02:45h )
    E:\Perl\eg>perl 2038.pl
    Mon Jan 18 23:14:01 2038
    Mon Jan 18 23:14:02 2038
    Mon Jan 18 23:14:03 2038
    Mon Jan 18 23:14:04 2038
    Mon Jan 18 23:14:05 2038
    Mon Jan 18 23:14:06 2038
    Mon Jan 18 23:14:07 2038

    Notese que el script se detiene en la septima fecha, como en Win2K. Uso ActivePerl build 635
    Al menos aqui si podemos culpar a Bill :)

    Espero tener algo mejor que este cacharro para esa fecha. WinXP tambien tendra el Y2K8?

    Bueno, es hora de espantarse!... tal vez no todavia... pero si dentro de unos 33 años....
    --

    Tom Maneiro
    PROJECT Spica - Director
    - http://t38.webhop.biz/ -

  • No veo el problema

    (Puntos:1)
    por Dr. Death (1744) el Domingo, 22 Agosto de 2004, 17:07h (#340906)
    ( http://barrapunto.com/ )
    Yo por esas fechas, lo más cutre que voy a tener va a ser un boli bic de 128 bits.

    Hodie undecimo Kalendas Septembres MMDCCLVII ab urbe condita est
    --
    Acabemos con las firmas reivindicativas

  • Hercules & Hidra en 16 bits.

    (Puntos:2, Inspirado)
    por locke (1530) el Domingo, 22 Agosto de 2004, 18:23h (#340931)
    ( http://ebro.gul.uc3m.es/~locke )
    Estaba paseando Hercules por el bosque y se encontró a la hidra. Y sacó Hercules la espada y e corto la cabeza, Y en vez de una cabeza, le crecieron 2. Y le cortó las 2 y le crecieron 4, y después 8, Y asi continuo la lucha durante 4 horas.
    Y le cortó Hercules, finalmente, 65536 cabezas. Y se murio la hidra, porque solo soportaba 16 bits.

  • Cojonudo

    (Puntos:2)
    por Epaminondas Pantulis (1747) el Domingo, 22 Agosto de 2004, 21:30h (#340993)
    ( http://hronia.blogalia.com/ | Última bitácora: Lunes, 02 Julio de 2007, 20:51h )
    Eso quiere decir que, si para el 2037 la jubilación no me llega para llegar a fin de mes, con 65 añitos podré dedicarme como freelance a parchear sistemas escritos en C++ y Java, para entonces lenguajes de dinosaurios...

    --
    ___
    "Tamparantán que te han visto Pepe, tamparantán que te han visto Juan"

  • ¡que way!

    (Puntos:1)
    por MelomanoArrepentido (14586) el Lunes, 23 Agosto de 2004, 07:24h (#341065)
    ( Última bitácora: Jueves, 10 Agosto de 2006, 10:10h )
    Tres años después de jubilarme vuelvo a nacer... ;)

  • Con el y2k se pedían programadores cobol

    (Puntos:1)
    por Redy (2212) <fidonet 2:348/609> el Lunes, 23 Agosto de 2004, 07:25h (#341066)
    ( http://parolas.thebbs.org )
    Recordais que los programadores cobol se hicieron unos buenos 'extras' cuando lo del efecto 2000. Lo que teneis que hacer es hacer que viestros hijos (o nietos) aprendan C, así en el 2037 seguro que les llueven las ofertas :-)
    --

    Redy Rodriguez (Fido 2:348/609) Parolas BBS

  • Comparto refugio atomico para dos....

    (Puntos:1)
    por calarena (8371) el Martes, 24 Agosto de 2004, 18:56h (#341963)
    ( Última bitácora: Jueves, 26 Enero de 2006, 09:32h )
    En bosque aislado con macizorra que nazca a partir del 2014. Abstenerse tios. Salu2.

  • Re:El signo de las fechas

    (Puntos:1)
    por Logann (12301) el Domingo, 22 Agosto de 2004, 11:26h (#340773)
    ( Última bitácora: Jueves, 01 Junio de 2006, 15:09h )
    Pobrecito hablador decia de ganar 1 bit, el bit de el singo, con solo 1 bit mas entonces si que tenemos el doble de tiempo. Pero eso comportaria un trato màs dificil de este double word.
    [ Padre ]

  • Complemento a dos

    (Puntos:1)
    por Wotan (12423) <JabberID: wotan@kdetalk.net> el Domingo, 22 Agosto de 2004, 14:47h (#340848)
    ( http://gauleng.blogspot.com/ )
    En la noticia dicen que para la fecha se usa una representación en complemento a dos. Es decir, el primer bit es el bit de signo, y el resto es la maginitud. Para establecer el valor de los números positivos se deja este bit a 0 y la magnitud en binario normal. Para calcular el opuesto de otro número, negamos todos los bits y sumamos 1:
    0111 -> +8
    1000 + 1 -> 1001 -> -8
    Cuando lleguemos al número 0111111111...111 (32 bits totales), el siguiente número será 1000000...00, que se corresponde con el máximo número negativo, es decir, restamos a partir de la fecha 1 de enero de 1970.
    Espero que me haya explicado correctamente :)
    [ Padre ]

  • No todo es linux

    (Puntos:1)
    por jariza (6768) <jariza___@___ieee.org> el Domingo, 22 Agosto de 2004, 21:15h (#340982)
    ( http://barrapunto.com/ )
    No todo es linux, aunque use timestamp de UNIX. Y si mal no recuerdo, solaris pasó la versión 2.8 hace un tiempecito.
    [ Padre ]

  • Re:peliculas del efecto 2038

    (Puntos:1)
    por KraMMeR (9571) <{elpunto} {at} {gmail.com}> el Lunes, 23 Agosto de 2004, 05:12h (#341056)
    Pero que la protagonice Keanu y la dirijan los W. Brothers! (no me pidais que escriba ese apellido)
    [ Padre ]
  • 13 respuestas por debajo de tu umbral de lectura actual.