El tiempo en Unix

Medir el tiempo es fundamental en cualquier sistema informático. Y el tiempo, si te paras a pensar, se puede medir de muchas maneras. Al final, medir el tiempo se puede resumir en contar intervalos periódicos y acumular esta cuenta o suma en algún lugar. En los sistemas Unix se utiliza desde sus orígenes un mecanismo llamado comúnmente "Tiempo Unix" o Tiempo POSIX. Consiste en contar el número de segundos que han transcurrido desde la medianoche del 1 de enero de 1970. Fecha que se toma como fundacional del sistema operativo. Esta acumulación de segundos se va guardando en una zona de memoria del kernel, una variable del sistema con un tamaño fijo.

El primer problema que muestra el Tiempo Unix es que ignora la existencia de los segundos intercalares o leap seconds. Estos segundos deben añadirse artificialmente al tiempo universal debido a que todos los días no duran lo mismo. Los programadores de Unix decidieron tomar un día como 86.400 segundos pero debido a perturbaciones en los movimientos de rotación de La Tierra, cada cierto tiempo hemos de añadir un segundo más porque vamos acumulando un error entre nuestro tiempo medido y el número de rotaciones que ha dado La Tierra entorno a su eje.

Otro problema que nos puede surgir en el futuro usando este Tiempo Unix es lo que se ha llamado el problema Y2K38 o problema 2038. La variable del sistema donde se guarda este contador tiene un tamaño fijo. Cada vez que sumamos uno, a dicha variable, nos vamos acercando más al límite máximo que esta variable puede almacenar. Imaginemos que esta variable tuviera un tamaño de 16 bits. Podríamos guardar un número binario que tuviera como máximo 16 1s. Veamos un ejemplo. Partimos de un variable de este tamaño con un contador todo a 0s, porque estamos a día 1 de enero de 1970. A partir de ahí, cada segundo vamos sumando 1 a esa variable y almacenando el valor en binario:

    ==  Tiempo transcurrido ==

 Decimal            Binario

    0           0000 0000 0000 0000 
        +1
    1           0000 0000 0000 0001
        +1
    2           0000 0000 0000 0010
        +1
    3           0000 0000 0000 0011
        +1
    4           0000 0000 0000 0100
        +1
    ....
    65.533      1111 1111 1111 1101
        +1
    65.534      1111 1111 1111 1110
        +1
    65.535      1111 1111 1111 1111
        +1
    65.536         ??????????

Como se puede ver, llegará un momento en el que habremos acumulado 65.534 segundos (tras unas 18 horas). Si sumamos un segundo más, el número se guardará como una secuencia de 16 unos. Pero entonces, ¿qué ocurrirá en el segundo siguiente? si sumamos uno más a ese número tendremos 65.536. Ese número necesita 17 bits para ser almacenado y no nos cabe en el espacio que hemos reservado para ese dato. En informática cuando intentamos guardar un dato demasiado grande en un espacio de memoria que no puede almacenarlo se produce un "desbordamiento". En los sistemas antiguos de Unix, esta variable no se almacena en 16 bits sino en 32 bits (en un tipo llamado time_t). Esto provocará que la variable se desborde el 19 de enero de 2038. La buena noticia es que la mayoría de sistemas que utilizamos a día de hoy son sistemas de 64 bits donde esta variable se ha dimensionado para no desbordar en mucho más tiempo. En concreto se ha calculado que, con 64 bits, el desbordamiento se daría dentro de 290 mil millones de años. La muerte térmica del universo sucederá antes así que no hay porque preocuparse.

Como curiosidad, si queréis saber el valor en Tiempo Unix de la fecha actual de vuestro sistema podéis usar el comando date +%s.