Cuando se usa un entero de 32 bits para almacenar un dato tipo ‘tiempo’ (fecha+hora), hay un overflow al que se llegaría en 2038.
No tanto por datos actuales, sino, por ejemplo, en un cálculo a futuro. ¿Que pasa un cálculo se extiende mas de 25 años?, ¿alguién ha probado esto con campos ‘tiempo’ (supongo que los campos ‘fecha’ no tendrían este problema, cierto)?
¿No sería otro argumento (aparte del límite de uso de memoria RAM) para ir ya trabajando con vServers y vClients en 64 bits, y tener herramientas de migración de campos ‘tiempo’ u otro tipo de datos que haga falta?
Aquí la idea del vClient 64 bits (que podría extenderse al vServer).
Primero, yo creo que como desarrolladores, no podemos tener ese principio de soluciones parche para dejarles el problema a otro, las soluciones deben ser bien construidas y no confirmarnos con que ‘por ahora’ no es problema.
Además, como explique en mi mensaje, pudo ser un cálculo. Por ejemplo, una hipoteca de mas de 25 años. No tenemos porque esperar que llegue el año para nos cause algún problema a nuestras aplicaciones.
Volviendo al tema, estuve revisando los campos tiempo, veo que guardan entre 1970 y 2106, y no guardan los milisegundos (que es el estándar en bases de datos, que ayudaba entre otras cosas, a generar un ID irrepetible de forma sencilla), por eso tienen mas rango.