A la hora de guardar datos en una base de datos donde sea necesario almacenar fechas a mi siempre me ha gustado almacenarlo todo, es decir, tanto la fecha como la hora, aunque realmente sólo se use una de las dos. Nunca se sabe como pueden evolucionar los requisitos de una aplicación.
Como en el trabajo usamos MySQL, para mis almacenamientos usaba el tipo de campo timestamp. Todos muy felices hasta que empecé a descubrir que la fecha de pedido se modificaba cada vez que hacía un update.
Leyendo la documentación de MySQL y consultando a mi amigo Dani (biólogo él pero controlando informática que lo flipáis) resulta que los tipos de campo timestamp se actualizan automáticamente a la fecha y hora actuales cada vez que hay una actualización del registro en la tabla. Sólo se podría quitar esta característica si la columna del timestamp fuese la segunda de dicho tipo, es decir, la primera de este tipo siempre se actualiza y a partir de ahí ya se puede quitar.
Por fin descubrimos el error, que nos ha costado, y es que este tipo de campo está pensado justamente para eso, para insertar la fecha de modificación automáticamente en cada registro implicado.
Pero claro, yo no quería eso, así que seguí investigando en la documentación de MySQL y descubrí que el campo que había que utilizar era el datetime. Internamente se representa igual que el timestamp pero no se actualiza automáticamente.
Es un error trivial y de principiante, pero me ha costado, si es que… Y como no quiero que lo cometa más gente (ni yo en futuras porgramaciones) pues aviso. Así que ya sabéis: timestamp para actualización automática de la fecha y la hora, datetime para guardar una fecha y hora modificada únicamente por el usuario.
Eso pasa por usar “MyNonStandardsCompliantSQL”… Mira que me gusta poco (y cada vez menos)…
Ah, con lo autentico que queda almacenar las fechas como un entero de 64 bits a la BeOS…