Hola a tod@s:
A raiz de la pregunta de Emma sobre el tema del
a�o bisiesto me he dado cuenta de que sigo programando las fechas con 8
d�gitos (el a�o con 4) cuando realmente ya no ser�a necesario ya que el
fat�dico cambio al a�o 2000 lo superamos hace tiempo y el cambio al 2100
no lo ver�n mis ojitos (que se tienen que comer los gusanos ;-)
Realmente no supone ning�n esfuerzo adicional de
programaci�n ya que, como la mayor�a, utilizo un �nico programilla que
convierte los formatos de fecha de 6 a 8 d�gitos para evitar que los
sufridos usuarios deban teclear siempre el prefijo 20 delante del a�o, pero no
cabe duda que a estas alturas del siglo XXI puede parecer un esfuerzo in�til
si calculamos, no ya el tiempo de proceso de cada conversi�n de fecha, sino
simplemente el espacio en disco que estamos "malgastando".
Pongamos un ejemplo, en una aplicaci�n t�pica de
contabilidad tenemos un fichero de movimientos contables, que puede tener como
campos de fecha:
- Fecha de grabaci�n
- Fecha de modificaci�n
- Fecha contable del asiento
- Fecha real del documento
Supongamos tambi�n que la fecha se guarda en
Hexadecimal con lo cual s�lo empleamos 1 d�gito adicional para grabar el a�o
con 4 d�gitos.
Esto supone 4 octetos por registro, parece una
cifra rid�cula pero si tenemos 500.000 apuntes al a�o nos encontramos que s�lo
para almacenar los movimientos contables necesitamos casi 2 Megas anuales
adicionales.
Y eso s�lo con un fichero, asi a ojo yo dir�a que
con la cantidad de ficheros que tengo y que almacenan campos de fecha puedo
estar "desperdiciando" unos 6 Mb s�lo para guardar el dichoso 20 que
precede al a�o.
Al precio que est�n los discos (17,54 Gb = 2.770
Euros m�s o menos) esos 6 Mb cuestan en Pesetas de toda la vida... (estoy
haciendo n�meros) �MENOS DE 2.000 Ptas.!
Vale, acabo de darme cuenta que tendr� que
intentar ahorrar por otro sitio, y es que los Megas ya no son lo que eran
;-)
Un saludo y perd�n por el rollo.
Juanra
