Tiempo embebido en un ID

Funciones

• Reconoce UUID (v1/v3/v4/v5/v6/v7/v8), ULID, ObjectId de MongoDB, ID Snowflake y FILETIME de Windows
• Convierte el tiempo embebido a una fecha ISO 8601 y explica el diseño de bits
• ⚠️ UUID v1 guarda su marca de tiempo desordenada en la cadena (los 32 bits bajos primero, los 12 altos al final): leerla en orden da un número del todo erróneo — aquí se trata aparte
• ⚠️ Los Snowflake se leen con BigInt: por encima de 2^53 un Number pierde los bits de secuencia mientras la marca de tiempo (bits altos) sigue pareciendo correcta, así que el error queda oculto
• ⚠️ El origen del Snowflake es una elección explícita (Twitter / Discord / Instagram / época Unix), con su efecto indicado en el resultado
• ⚠️ Los ULID se comprueban contra la regla que casi todos los validadores se saltan: el primer carácter debe ser 0–7 (los dos bits sobrantes de una codificación de 130 bits deben ser cero, y cualquier valor mayor desborda los 128 bits). Una comprobación de longitud y alfabeto los deja pasar y decodifica una fecha a décadas de distancia
• Los ULID en minúsculas, o con I / L / O, se recuperan con las reglas de ambigüedad de Crockford (I y L valen 1, O vale 0) y se marcan como no canónicos
• Los campos del ObjectId se listan por separado — cuatro bytes de segundos, cinco de aleatoriedad por proceso y tres de contador — porque el orden dentro de un mismo segundo sale de esos últimos seis caracteres
• Los tipos sin marca de tiempo, como v4, lo dicen en vez de dejar la casilla en blanco
• Pega varios ID, uno por línea, agrupados por línea

Cómo se usa

1. Pega uno o varios ID, uno por línea
2. Si es un Snowflake, ajusta el origen con el que se generó
3. El resultado da el tipo, el tiempo embebido y la explicación del diseño de bits

Preguntas frecuentes

¿Por qué no hay un único origen para Snowflake?

Porque Snowflake es un diseño de bits (la marca de tiempo desplazada 22 bits, con máquina y secuencia en los bits bajos), no un formato estándar: cada plataforma eligió su propio origen. Twitter usa el 2010-11-04, Discord el 2015-01-01 e Instagram el 2011-08-24. El mismo número da una fecha verosímil bajo cualquiera de esos supuestos y nunca da error, por eso aquí te obliga a elegir y deja constancia de cuál elegiste.

¿Qué diferencia hay entre UUID v7 y v4?

v4 es totalmente aleatorio y sin estructura; v7 pone milisegundos Unix en los primeros 48 bits, así que se ordena por fecha de creación. En una base de datos eso pesa: una clave primaria v4 reparte los puntos de inserción por todo el B-tree, mientras que v7 se acerca a la escritura secuencial. El precio es que v7 filtra su fecha de creación: si eso es sensible, no uses v7.

¿Por qué la marca de tiempo de UUID v1 no se puede leer en orden?

Porque la especificación parte la marca de tiempo de 60 bits en tres trozos y coloca los 32 bits bajos primero: la cadena va `time_low` (32 bits), `time_mid` (16 bits) y luego `time_hi` (12 bits) compartiendo campo con el número de versión. Leerla como un entero en orden da un valor del todo erróneo que aun así parece una hora razonable y no da error. v6 existe precisamente para reordenar esos tres trozos con los bits altos delante.

ObjectId y Snowflake llevan tiempo: ¿en qué se diferencian?

Un ObjectId es el valor de 12 bytes de MongoDB: 4 bytes de segundos, 5 bytes de aleatoriedad por proceso y un contador de 3 bytes, con precisión de segundo. Un Snowflake es un entero de 64 bits con precisión de milisegundo, y los bits restantes se reparten entre máquina y secuencia. Por eso dos ObjectId creados en el mismo segundo no se pueden ordenar por su propio contenido, y dos Snowflake sí.