Sporepedia 2
¡Bienvenido a Sporepedia 2! Si quieres empezar a compartir tus creaciones y descargar las de otros, regístrate ya.

Y2K38 - El inevitable y destructivo problema del año 2038 DL4SYdk
Conectarse

Recuperar mi contraseña

Últimos temas
» El Iceberg Definitivo del Foro [PROYECTO COMUNITARIO]
Y2K38 - El inevitable y destructivo problema del año 2038 CVRdAIRHoy a las 14:57 por FlairDreamer

» Experimento Scarver-T [Virus-T]
Y2K38 - El inevitable y destructivo problema del año 2038 CVRdAIRHoy a las 14:27 por Quincho96

» Caballo [3lite vs. Xhaps] [2]
Y2K38 - El inevitable y destructivo problema del año 2038 CVRdAIRHoy a las 11:50 por Sirillium64

» Esidisi's Tower [O4] [E]
Y2K38 - El inevitable y destructivo problema del año 2038 CVRdAIRHoy a las 11:47 por Sirillium64

» ¿Que música están escuchando?
Y2K38 - El inevitable y destructivo problema del año 2038 CVRdAIRHoy a las 11:44 por FlairDreamer

» Hola
Y2K38 - El inevitable y destructivo problema del año 2038 CVRdAIRHoy a las 11:29 por FlairDreamer

» Problema con los pies de DI y otros mods
Y2K38 - El inevitable y destructivo problema del año 2038 CVRdAIRAyer a las 20:10 por FlairDreamer

» Las partes robóticas en mi spore no funcionan bien
Y2K38 - El inevitable y destructivo problema del año 2038 CVRdAIRAyer a las 20:08 por FlairDreamer

» ¿Cómo recuperar una criatura borrada?
Y2K38 - El inevitable y destructivo problema del año 2038 CVRdAIRAyer a las 19:22 por FlairDreamer

» Una decada despues!
Y2K38 - El inevitable y destructivo problema del año 2038 CVRdAIRMar 12 Nov 2024, 22:31 por Endy

» Prototipo Zangief [O3]
Y2K38 - El inevitable y destructivo problema del año 2038 CVRdAIRMar 12 Nov 2024, 19:09 por Quincho96

» El traveler barato de Owari [TA] [Mx3]
Y2K38 - El inevitable y destructivo problema del año 2038 CVRdAIRMar 12 Nov 2024, 16:12 por Quincho96

» Golem Guardian [DoT][21] (Golem)
Y2K38 - El inevitable y destructivo problema del año 2038 CVRdAIRLun 11 Nov 2024, 16:14 por Quincho96

» Rise of Cults 2 Bot (Beta abierta)
Y2K38 - El inevitable y destructivo problema del año 2038 CVRdAIRDom 10 Nov 2024, 01:12 por XleandroX

» Nueva Ciudad Sporepedia 2024 (Historia por partes)
Y2K38 - El inevitable y destructivo problema del año 2038 CVRdAIRSáb 09 Nov 2024, 19:48 por Sirillium64

» Los experimentos del Dr. Breincrox, parte 2
Y2K38 - El inevitable y destructivo problema del año 2038 CVRdAIRSáb 09 Nov 2024, 19:45 por Sirillium64

» TEMA FLOOD
Y2K38 - El inevitable y destructivo problema del año 2038 CVRdAIRVie 08 Nov 2024, 18:37 por FlairDreamer

» nuevo juego
Y2K38 - El inevitable y destructivo problema del año 2038 CVRdAIRVie 08 Nov 2024, 11:48 por thescientist9393

» L-14 [O3] [A]
Y2K38 - El inevitable y destructivo problema del año 2038 CVRdAIRMiér 06 Nov 2024, 22:45 por Quincho96

» Pide un deseo y arruina al de arriba 2º Parte
Y2K38 - El inevitable y destructivo problema del año 2038 CVRdAIRMar 05 Nov 2024, 20:01 por Quincho96

» Mataría al de arriba porque.... 2º Parte
Y2K38 - El inevitable y destructivo problema del año 2038 CVRdAIRMar 05 Nov 2024, 18:54 por El Destructor de Especies

» Extensión de Chrome: Sporepedia Downloader [1.2]
Y2K38 - El inevitable y destructivo problema del año 2038 CVRdAIRJue 31 Oct 2024, 09:57 por FlairDreamer

» Cambios de Nick
Y2K38 - El inevitable y destructivo problema del año 2038 CVRdAIRDom 27 Oct 2024, 14:55 por FlairDreamer

Creación Aleatoria
Hora Mundial

Y2K38 - El inevitable y destructivo problema del año 2038

Ver el tema anterior Ver el tema siguiente Ir abajo

Y2K38 - El inevitable y destructivo problema del año 2038 Empty Y2K38 - El inevitable y destructivo problema del año 2038

Mensaje por Nestorsaurus [GC] Miér 09 Mar 2016, 13:01

Algunos lo sabían, otros no. Bueno, en resumen es un problema como el Y2K del 2000 pero más devastador.

Sacado de Wikipedia:
En informática, el problema del año 2038 (conocido también por el numerónimo Y2K38) podría causar que una parte del software falle en ese año. El problema afecta a los programas que usen la representación del tiempo basada en el sistema POSIX, que se basa en contar el número de segundos transcurridos desde el 1 de enero de 1970 a las 00:00:00 (ignorando los segundos intercalares). Las últimas versiones del kernel Linux comienzan a contar desde las 21:00 del 31 de diciembre de 1969. En Android, ocurre lo mismo, ya que utiliza esta versión de kernel, aunque no es posible seleccionar la fecha desde el menú de ajustes.

Esta representación es un estándar de facto en los sistemas tipo Unix y también en los programas escritos para muchos otros sistemas operativos debido al gran alcance del lenguaje de programación C. En la mayoría de sistemas de 32 bits, el tipo de dato time_t usado para guardar el contador de segundos es un entero de 32 bits con signo, es decir, que puede representar un rango de números entre -2 147 483 648 y 2 147 483 647 (-231 y 231-1; 1 bit para el signo, y 31 para representar su valor en complemento a dos), por lo que 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 2 147 483 647. Un segundo después, el contador se desbordará y saltará al valor -2 147 483 648, que causará el fallo de programas que interpretarán el tiempo como que están en 1901 (dependiendo de la implementación), en vez de en 2038. A su vez, esto causaría cálculo y procesamiento incorrecto y causaría un problema mundial. Los sistemas que cuentan la hora desde (21:00 31/12/1969) llegaran a su tope a las 00:14:07.

No hay una forma sencilla de arreglar este problema para las combinaciones existentes de CPU/SO. Cambiar la definición de time_t para usar un tipo de 64 bits rompería la compatibilidad binaria para el software, almacenamiento de datos y, por lo general, cualquier cosa que tenga algo que ver con la representación binaria del tiempo. Cambiar time_t a un entero de 32 bits sin signo afectaría a los programas que hacen cálculos con diferencias de tiempo.

La mayoría de sistemas operativos para arquitecturas de 64 bits utilizan enteros de 64 bits para time_t. La migración a estos sistemas está todavía en proceso y se espera que se complete mucho antes de 2038. Usar un entero de 64 bits retrasaría la fecha del problema unos 2,90 billones de años (2,9 × 1012). Es decir, 220 veces la edad aproximada del Universo.

Espero que no afecte a S2 :odioso:

Volver arriba Ir abajo

Y2K38 - El inevitable y destructivo problema del año 2038 Empty Re: Y2K38 - El inevitable y destructivo problema del año 2038

Mensaje por FlairDreamer Miér 09 Mar 2016, 14:05

Creo que lo había escuchado por ahí. Bueno, aún le quedan unos 22 años, esperemos que en ese tiempo hagan algo al respecto. Yao Ming

Volver arriba Ir abajo

Y2K38 - El inevitable y destructivo problema del año 2038 Empty Re: Y2K38 - El inevitable y destructivo problema del año 2038

Mensaje por technoguyx Miér 09 Mar 2016, 20:37

Para entonces ya vamos a estar ocupando procesadores cuánticos para jugar Half-Life 3 y Spore 2, mientras robots nos limpian la casa y nos dan comida. Yao Ming

El problema es relativamente viejo y creo que ya hay algunos sistemas que utilizan un formato de 64 bits. Eso permitiría representar el tiempo hasta las 15:30:08 UTC del Domingo 4 de Diciembre del año 292.277.026.596. c:

Volver arriba Ir abajo

Y2K38 - El inevitable y destructivo problema del año 2038 Empty Re: Y2K38 - El inevitable y destructivo problema del año 2038

Mensaje por Spinosaurus Supersapiens Jue 10 Mar 2016, 17:04

Este "anuncio" me recordó a los Simpsons Yao Ming

Sep, esto es de hace años, es difícil que se repita, Nestor.

Volver arriba Ir abajo

Y2K38 - El inevitable y destructivo problema del año 2038 Empty Re: Y2K38 - El inevitable y destructivo problema del año 2038

Mensaje por Contenido patrocinado

Volver arriba Ir abajo

Ver el tema anterior Ver el tema siguiente Volver arriba

- Temas similares

Permisos de este foro:
No puedes responder a temas en este foro.