En los comentarios ya hubo gente que lo adivinó, aunque otra, que iba en buen camino, no halló respuesta porque "no le cuadraban las cuentas".
Efectivamente tiene que ver con la "hora unix". Los sistemas operativos Unix no conocen fechas anteriores al 1 de Enero de 1970, lo que para estos sistemas se podría decir que consideran "el principio del mundo". La hora Unix cuenta simplemente los segundos que pasan desde esa fecha, sin contar los segundos añadidos por ajustes de calendario (esto, la hace más inexacta cuanto más pasa el tiempo).
Pues bien, el 03 de Marzo de 1973 a las 10:46:40 se cumplieron 100.000.000 de segundos desde esa fecha, y el 09 de Septiembre de 2001 a las 03:46:40 se cumplió el segundo 1.000.000.000 y se le conoce comunmente como el día del "Unix billennium" (recordemos que para los americanos 1000 millones es 1 billón). Por seguir con dicho orden, añadiéndole un cero más tendremos el segundo 10.000.000.000 que se cumplirá en el 2014.
Las pequeñas incongruencias que ha podido haber en otros resultados ha podido ser por los ajustes GMT que tengan cada sistema, porque en muchas configuraciones los sistemas cuentan en sus cálculos la franja horaria donde está el servidor (GMT) y de ahí las derivaciones, tanto mías como de otros ordenadores, pero aun así, la pregunta, si se sabía "por donde podía ir" era respondible con ese pequeño margen de error.
Precisamente a mi me ha pasado puesto que con GMT+2 (España horario verano), la hora del segundo 1.000.000.000 me salía las 03:46:40, mientras que en UTC (tiempo coordinado Universal) son las 01:46:40.
Otra fecha muy curiosa que pasará dentro de poco es a las 23:31:30 UTC del 13 de Febrero de 2009, donde se podrá celebrar el segundo 1234567890, un número bonito…
El problema que ha habido con la tercera fecha es un problema de overflow, es decir, de número desbordado. El tiempo Unix tiene como máximo el 19 de Enero de 2038, a las 03:14:07 y por tanto, los intentos de utilizar funciones (como las de PHP) para calcular que fecha es un segundo en concreto, se desborda y empieza a contar de nuevo. Esto lo vemos claramente en las siguientes fechas sacadas con PHP:
El segundo 1000000000 es: 09-09-2001 a las 03:46:40
El segundo 2000000000 es: 18-05-2033 a las 05:33:20
El segundo 3000000000 es: 18-12-1928 a las 23:51:44
El segundo 4000000000 es: 27-08-1960 a las 01:38:24
El segundo 5000000000 es: 05-05-1992 a las 04:25:04
El segundo 6000000000 es: 12-01-2024 a las 05:11:44
El segundo 7000000000 es: 15-08-1919 a las 00:30:08
El segundo 8000000000 es: 23-04-1951 a las 02:16:48
El segundo 9000000000 es: 30-12-1982 a las 04:03:28
El segundo 10000000000 es: 07-09-2014 a las 06:50:08
No se sabe que pasará en esa fecha del 2038, pero lo que es seguro que toda la programación de muchísimos servidores se tendrá que cambiar, y posiblemente, aunque no se hunda el mundo, como tampoco pasó con el Efecto 2000, pero si que haya que invertir una millonada a nivel mundial para paliar este error.
Quizá cuando se inventó el tiempo Unix no se pensaba que la informática iba a tener tanta vida…
Se puede aprender mucho de este tiempo en ésta página de la Wikipedia aunque está en inglés. Es un tiempo muy usado en prácticamente todas las programaciones y que debería ser más exacto y revisado porque no tiene toda la precisión necesaria para tanto sistema informático que depende de él, aun así, se van haciendo variaciones de vez en cuando, pero ya es tratar el tema demasiado profundo y no es plan aquí.
Así que la respuesta, como bien dijo uno en los comentarios, en esas fechas se añadió un dígito más al número de segundos que han pasado desde el 1 de Enero de 1970, o lo que es lo mismo, desde que empezó el "tiempo Unix".
Para los programadores algo de código:
En PHP se puede hacer de la siguiente manera:
echo date("d-m-Y \a \l\a\s H:i:s", 100000000);
echo date("d-m-Y \a \l\a\s H:i:s", 1000000000);
echo date("d-m-Y \a \l\a\s H:i:s", 10000000000);Y en MYSQL así
select from_unixtime(100000000);
select from_unixtime(1000000000);
Pues difiero contigo con especto a que “tomara una millonada reparar el problrma” como sucedio en el 2000 ya que estoy seguro que facilmente y de forma barata se solucionara ese conteo de la fecha, con alguna actualizacion del sistema. Si basas el codigo que escribiste para sacar la fecha en php con la actualizacion del unixtime se solucionara y no tendras que entrar a arreglar el codigo de php por lo que no se invertira en programadores, desarrolladores, etc.
9 de agosto de 2007El problema del Unix Time que en el año 2038 fallara debido a un overflow del contador de los segundos en los procesadores de 32-bit.
9 de agosto de 2007Creo que para ese añ0 los procesadores de 64-bit (o mas) estaran en todas las computadoras.
Mas info en http://es.wikipedia.org/wiki/Problema_del_año_2038.
Que interesate, creo que pudiste haber resumido la respuesta.
9 de agosto de 2007Ni por donde,andaba super perdida.Estoy d acuerdo con El_Papa.
9 de agosto de 2007frikis sucks
9 de agosto de 2007Vi no se dónde que no tenemos que preocuparnos por el 2038 porque para entonces se utilizarán arquitecturas de 64 bits y los tipos básicos de datos tendrán el doble de capacidad…
9 de agosto de 2007El desbordamiento de la hora Unix se produce en sistemas de 32 bits. En los de 64 la estructura, al ser mucho más grande da un margen bastante “holgado”.
En el caso de usar un entero de 32 bits con signo tenemos un rango de 68 años (2^32 /2/60/60/24/365). Pero en el caso de los 64 bits tenemos un rango de más de 292.471 millones de años.
La pregunta es entonces ¿Cuantos sistemas de 32 bits quedarán en el 2038? Supongo que servidores pocos pero sistemas embebidos (maquinas expendedoras, ascensores, televisores, etc) habrá unos cuantos, al igual que hoy los hay de 8 bits.
9 de agosto de 2007FRIKI!!!!jijijiji sin acritud
9 de agosto de 2007Yo… compraros un perro e id a pasead a la playa que la vida es muy corta.
9 de agosto de 2007ya tengo perro: http://86400.es/puck
9 de agosto de 2007>>> print datetime.fromtimestamp(100000000)
1973-03-03 10:46:40
>>> print datetime.fromtimestamp(1000000000)
2001-09-09 03:46:40
>>> print datetime.fromtimestamp(10000000000)
2286-11-20 18:46:40
Habrá que esperar un poco para el siguiente dÃgito…
9 de agosto de 2007Lo FRIKI no es la pregunta ni la respuesta…. LO REALMENTE FRIKI es que después de la respuesta… la peña empieza a analizar y dar más opiniones !!!!!
JAJAJAJA….
QUÉ BARBARIDAD !!!
9 de agosto de 2007lo que dice caracol es cierto !!
Y no se cumple lo que dice aquel refran de que despues de la tormenta siempre llega la calma porque hay mas preguntas con la llegada de la respuesta !!
Lo interesante fuera que Roberto nos explicara como es ese rango “holgado” sobre esos 292.471 millones de años gracias a la arquitectura de 64 bits.
Pero bien, todavia falta tiempo para el 2038, asi que no me preocupo, aun puedo seguir con mi Celeron D a 2.58 Ghz a 32 bits
9 de agosto de 2007saludos :)
“pedro y pablo”, a ver si mejoras tu inglés antes de soltar frasecitas hechas… imbécil.
9 de agosto de 2007Pues un poco friki si que es… yo me quedo con mi reloj de pulsera jeje ;)
11 de agosto de 2007