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);