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
