Cómo leer un UUID a mano: versión, variante y la fecha que lleva dentro

Un UUID son 128 bits escritos como 32 dígitos hexadecimales y, contra lo que parece, no son opacos. En la posición 12 de esa cadena —sin guiones, contando desde cero— va la versión; en la 16, la variante; y en tres de los formatos hay una marca de tiempo incrustada. Un desarrollador ha publicado el decodificador que lo saca sin dependencias, y lo útil de su nota no es la herramienta, sino cómo se convenció de que no estaba mal.

Las posiciones que importan

La forma canónica agrupa los 32 dígitos en 8-4-4-4-12, pero para leerlos conviene borrar los guiones. Con la cadena plana, el carácter 12 dice la versión (1, 3, 4, 5, 6, 7 u 8) y el 16 la variante. Esta segunda es la parte que casi nadie recuerda: los dos bits altos de ese nibble marcan la familia. El patrón 10 corresponde a RFC 4122, que RFC 9562 recoge, y es lo que usa prácticamente todo lo que circula hoy; por debajo quedan linajes antiguos como NCS o el GUID de Microsoft.

Tres versiones llevan tiempo dentro. En v7 los primeros 48 bits son milisegundos desde la época Unix y basta con leerlos como número. En v1 y v6 son intervalos de 100 nanosegundos desde el 15 de octubre de 1582, así que hay que restar los 12.219.292.800.000 ms que separan esa fecha de 1970. La trampa está en que v1 reparte sus 60 bits entre time_low, time_mid y time_hi desordenados, y hay que reensamblarlos de mayor a menor; v6 guarda esos mismos campos ya en orden ascendente, de modo que la concatenación se invierte. v4 es aleatorio y v3 y v5 son hashes de nombre: ahí no hay nada que recuperar.

Dos caminos para la misma fecha

El código tiene dos detalles que se rompen en silencio. El primero son las máscaras de la variante: hay que probarlas de estrecha a ancha (&0x8, después &0xc, después &0xe). Si se empieza por la de Microsoft, los UUID de RFC se clasifican mal. El segundo, que v7 no necesita BigInt: 48 bits son unos 2,8·10^14, muy por debajo del máximo entero seguro de JavaScript, así que parseInt llega. v1 sí lo necesita, por el reordenado de campos.

Y queda el problema de fondo. Desplazar un límite de campo un solo dígito no devuelve un valor roto, devuelve otra fecha igual de creíble. Los tests propios no sirven como red de seguridad, porque el valor esperado lo escribió la misma persona que pudo leer mal la especificación. Lo que valida el decodificador es que RFC 9562 publica un ejemplo v1 y otro v7 que designan el mismo instante. Son dos codificaciones distintas, resueltas por ramas distintas del programa, y ambas caen en 2022-02-22T19:22:22.000Z. Si el reparto de campos fuera incorrecto, esa coincidencia no aparecería.

Hasta aquí el ejercicio. En el día a día, un identificador que llega de otro sistema y no trae documentación se puede fechar si es v1, v6 o v7, que es la mitad menos vistosa pero la que se usa de verdad.