Límite de campos tiempo en 32 bits, ¿previsto en v7?


([N4] mittosoftware) #1

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

Aqui el artículo de referencia.

http://www.informationweek.com/byte/personal-tech/25-years-from-today-a-time-for-bugs/240146640

¿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).

http://velneo.zendesk.com/entries/21618173-vclient-64-bit


([N1] wikan) #2

A lo mejor ni llegamos al 2038, no creo que tampoco demasiado problema por ahora.

 


([N4] mittosoftware) #3

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.