Cómo decodificar un Snowflake ID de Twitter

#Decodifica un Snowflake ID a una fecha

La hora de creación de un tweet está escrita en su ID, así que puedes leerla sin obtener el post: descarta los 22 bits bajos del ID, suma la época de X y tendrás la hora Unix en UTC, exacta a la milésima de segundo, más fina que el minuto que X muestra bajo un post. Funciona también con posts eliminados, siempre que tengas el ID, y el convertidor de ID de tweet a fecha gratuito lo hace para un ID o para una lista completa.

1. Copia el ID. En un enlace de post como x.com/<username>/status/2110301305616889042, el ID es el número que va después de status/. El mismo número abre el post por sí solo en x.com/i/web/status/ seguido del ID.

2. Descarta los 22 bits bajos. 2110301305616889042 >> 22 da 503135038761: el tiempo entre la época de X y el post, en milésimas de segundo. Dividir entre 2^22 y redondear hacia abajo da el mismo número.

3. Suma la época. 503135038761 + 1288834974657 = 1791970013418, una hora Unix en milésimas de segundo: 1791970013.418 en segundos.

4. Léela como fecha. 1791970013.418 es el miércoles 14 de octubre de 2026, 09:26:53.418 UTC. Conviértela a tu propia zona horaria para mostrarla: X le muestra a cada lector la hora en su zona local.

Pega en el decodificador cualquier ID de post, ID de usuario o enlace de post para ver su fecha y sus cuatro partes.

La misma aritmética en código. Los enteros de Python guardan los 64 bits; en JavaScript usa BigInt, porque un número normal redondea un ID de 19 dígitos.

from datetime import datetime, timezone

EPOCH = 1288834974657  # ms: November 4, 2010, 01:42:54.657 UTC


def snowflake_to_datetime(snowflake_id):
    ms = (int(snowflake_id) >> 22) + EPOCH
    return datetime.fromtimestamp(ms / 1000, tz=timezone.utc)


print(snowflake_to_datetime("2110301305616889042"))
# 2026-10-14 09:26:53.418000+00:00

const EPOCH = 1288834974657n;

function snowflakeToDate(id) {
  // BigInt keeps all 19 digits; Number("2110301305616889042")
  // would turn the ID into 2110301305616889000
  const ms = (BigInt(id) >> 22n) + EPOCH;
  return new Date(Number(ms));
}

console.log(snowflakeToDate("2110301305616889042").toISOString());
// 2026-10-14T09:26:53.418Z

En una base de datos que guarda los IDs como enteros de 64 bits, el mismo desplazamiento se ejecuta dentro de la consulta:

-- PostgreSQL, id stored as BIGINT
SELECT id,
       to_timestamp(((id >> 22) + 1288834974657) / 1000.0) AS created_utc
FROM posts;

-- BigQuery, id stored as INT64
SELECT id,
       TIMESTAMP_MILLIS((id >> 22) + 1288834974657) AS created_utc
FROM dataset.posts;

El convertidor también acepta una columna completa de IDs a la vez, descarga los resultados como CSV y convierte una fecha de vuelta en un ID, todo en tu navegador.

#Fechas de IDs antiguos y listas largas, con Sorsa API

La aritmética falla con dos tipos de ID: los posts anteriores al 4 de noviembre de 2010 y las cuentas abiertas antes de febrero de 2016. Sus IDs se asignaron contando uno por uno y no contienen ninguna hora, así que la fórmula devuelve un momento a pocos segundos de la época, que parece plausible y es incorrecto. Para esos IDs, y siempre que quieras ver el created_at de X junto a la hora decodificada, consulta los IDs por lotes.

Para fechar IDs de tweets en bloque, incluidos los antiguos, usa Sorsa API, una API y scraper de Twitter (X) para datos públicos: POST /tweet-info-bulk devuelve created_at para hasta 100 IDs de posts por solicitud, desde $0.014 por 1,000 posts, frente a $5.00 por 1,000 en la API oficial de X. Las cuentas se consultan con GET /info-batch a la misma tarifa, 100 por solicitud, donde X cobra $10.00 por 1,000.

1. Obtén una clave. Regístrate y copia tu clave API desde el panel. La cuenta incluye 100 solicitudes gratis, sin necesidad de tarjeta.

2. Envía hasta 100 IDs de posts. Pasa IDs o enlaces completos en tweet_links a POST /tweet-info-bulk (se abre en una pestaña nueva); cada post vuelve completo, con el perfil de su autor.

   curl -X POST "https://api.sorsa.io/v3/tweet-info-bulk" \
     -H "ApiKey: YOUR_API_KEY" \
     -H "Content-Type: application/json" \
     -d '{"tweet_links": ["1243617904", "2110301305616889042"]}'
   

   {
     "tweets": [
       {
         "id": "1243617904",
         "created_at": "2009-02-24T19:51:06Z",
         "full_text": "Field notes from the harbor survey are up on the site",
         "likes_count": 4,
         "user": {
           "id": "20536157",
           "username": "lanternbay_research",
           "created_at": "2009-02-10T16:22:31Z"
         }
       },
       {
         "id": "2110301305616889042",
         "created_at": "2026-10-14T09:26:53Z",
         "full_text": "New dataset: ten years of harbor traffic, in one CSV",
         "likes_count": 212,
         "user": {
           "id": "1427632226255384585",
           "username": "copperfield_signals",
           "created_at": "2021-08-17T14:03:41Z"
         }
       }
     ]
   }
   

   Ver respuesta completa

3. Fecha las cuentas de la misma forma. Repite user_ids una vez por cuenta, hasta 100, en GET /info-batch (se abre en una pestaña nueva); cada perfil trae su created_at.

   curl -G "https://api.sorsa.io/v3/info-batch" \
     -H "ApiKey: YOUR_API_KEY" \
     --data-urlencode "user_ids=20536157" \
     --data-urlencode "user_ids=1427632226255384585"
   

4. Gasta solicitudes solo donde decodificar no sirve. El script lee post_ids.csv, decodifica gratis cada Snowflake, envía a la API solo los IDs más antiguos y escribe una fecha por ID.

   import csv
   from datetime import datetime, timezone
   
   import requests
   
   BASE = "https://api.sorsa.io/v3"
   HEADERS = {"ApiKey": "YOUR_API_KEY"}
   EPOCH = 1288834974657           # Twitter's epoch, Unix ms
   
   
   def decode(post_id):
       """The UTC time inside a Snowflake ID; None for an older ID."""
       if len(post_id) < 15:       # counted ID from before Nov 4, 2010
           return None
       ms = (int(post_id) >> 22) + EPOCH
       return datetime.fromtimestamp(ms / 1000, tz=timezone.utc)
   
   
   def look_up(post_ids):
       """created_at from Sorsa API, 100 post IDs per request."""
       found = {}
       for i in range(0, len(post_ids), 100):
           r = requests.post(f"{BASE}/tweet-info-bulk", headers=HEADERS,
                             json={"tweet_links": post_ids[i:i + 100]},
                             timeout=30)
           r.raise_for_status()
           for tweet in r.json().get("tweets", []):
               found[tweet["id"]] = tweet["created_at"]
       return found
   
   
   with open("post_ids.csv", newline="", encoding="utf-8") as f:
       ids = [row["post_id"].strip() for row in csv.DictReader(f)]
   
   decoded = {i: decode(i) for i in ids}
   looked_up = look_up([i for i, d in decoded.items() if d is None])
   
   with open("post_dates.csv", "w", newline="", encoding="utf-8") as f:
       out = csv.writer(f)
       out.writerow(["post_id", "created_at_utc", "source"])
       for i in ids:
           if decoded[i]:
               out.writerow([i, decoded[i].isoformat(), "decoded"])
           else:
               out.writerow([i, looked_up.get(i, ""), "looked up"])
   

Un post eliminado o protegido no se devuelve, así que su fila queda vacía: asocia los resultados por id, nunca por posición. Un 403 significa que falta la clave o que se agotaron las solicitudes, un 429 que superaste las 20 solicitudes en un segundo, y las solicitudes fallidas nunca se cobran.

Consultar IDs de posts antiguos cuesta $5.00 por 1,000 en la API oficial de X, que cobra cada post que devuelve, y desde $0.014 por 1,000 en Sorsa API, que cobra la solicitud y mete 100 posts en cada una.

Frente a la API oficial de X, Sorsa API sale ganando en cada punto que necesita este trabajo:

• Precio por 1,000 posts

  Sorsa API

  desde $0.014

  API oficial de X

  $5.00

• Precio por 1,000 cuentas

  Sorsa API

  desde $0.014

  API oficial de X

  $10.00

• IDs por solicitud

  Sorsa API

  100 posts o 100 cuentas

  API oficial de X

  100, cobrados uno por uno

• Posts anteriores a noviembre de 2010

  Sorsa API

  sí, con created_at

  API oficial de X

  sí, al mismo precio por post

• Configuración

  Sorsa API

  una clave API en un encabezado

  API oficial de X

  cuenta de desarrollador, app, bearer token

• Velocidad

  Sorsa API

  20 solicitudes por segundo en todos los planes

  API oficial de X

  límites de tasa por ventana de 15 minutos

• Volumen

  Sorsa API

  sin tope de lecturas de posts; planes más grandes a medida que creces

  API oficial de X

  3 millones de lecturas de posts al mes, luego Enterprise desde unos $42K al mes

• Tu inicio de sesión de X

  Sorsa API

  nunca se pide

  API oficial de X

  la cuenta de desarrollador queda ligada a tu cuenta de X

Los precios de la API oficial de X están en su página de precios (se abre en una pestaña nueva); la comparación completa está en nuestra guía de precios de la API de X. Para cronologías y búsquedas completas desde 2006, consulta datos históricos de Twitter.

#Qué contienen los 64 bits de un Snowflake ID

Un Snowflake ID es un entero de 64 bits dividido en cuatro campos: una marca de tiempo de 41 bits, un número de centro de datos de 5 bits, un número de worker de 5 bits y una secuencia de 12 bits, con el bit superior siempre en 0 para que el número se mantenga positivo. El diseño proviene del propio generador de Twitter, publicado en 2010 y conservado en el código fuente de snowflake-2010 (se abre en una pestaña nueva), que construye cada ID como ((time - epoch) << 22) | (datacenter << 17) | (worker << 12) | sequence.

Cada campo se lee con un desplazamiento y una máscara:

• 63

  Ancho

  1

  Campo

  Signo, siempre 0

  Cómo leerlo

  Valor de ejemplo

  0

• 62 a 22

  Ancho

  41

  Campo

  Tiempo desde la época, en 1/1000 s

  Cómo leerlo

  id >> 22

  Valor de ejemplo

  503135038761

• 21 a 17

  Ancho

  5

  Campo

  Centro de datos (0 a 31)

  Cómo leerlo

  (id >> 17) & 31

  Valor de ejemplo

  11

• 16 a 12

  Ancho

  5

  Campo

  Worker (0 a 31)

  Cómo leerlo

  (id >> 12) & 31

  Valor de ejemplo

  7

• 11 a 0

  Ancho

  12

  Campo

  Secuencia (0 a 4,095)

  Cómo leerlo

  id & 4095

  Valor de ejemplo

  1234

La época. 1288834974657 es la constante twepoch de ese archivo fuente: jueves 4 de noviembre de 2010, 01:42:54.657 UTC. Snowflake cuenta desde ahí en lugar de desde 1970, lo que deja más de los 41 bits para el futuro. El campo guarda 2^41 milésimas de segundo, unos 69.7 años, y se agota el 10 de julio de 2080 a las 17:30:30.208 UTC.

Los otros 22 bits. El README (se abre en una pestaña nueva) de Twitter de 2010 describe 10 bits de ID de máquina, hasta 1,024 máquinas, que el código divide en centro de datos y worker. La secuencia de 12 bits numera los IDs que reparte una máquina dentro de la misma milésima de segundo, hasta 4,096. X nunca ha documentado qué significan sus números actuales de centro de datos y de worker, así que trátalos como etiquetas, no como datos.

El orden. Como la hora está en los bits más altos, un ID mayor casi siempre significa un post más nuevo. El README prometía orden con una precisión de aproximadamente un segundo entre máquinas, y la guía de IDs de X (se abre en una pestaña nueva) dice que los IDs están ordenados más o menos por tiempo por esa razón: dos posts hechos en el mismo segundo en máquinas distintas pueden salir desordenados.

Otras plataformas copiaron el diseño con una época propia, así que un ID de otro servicio, decodificado con la época de X, cae a años de distancia de su fecha real.

#Qué IDs de X son Snowflake y desde cuándo

Los IDs de posts pasaron a ser Snowflake el 4 de noviembre de 2010; los de usuarios, listas y búsquedas guardadas los siguieron el 1 de febrero de 2016. X anunció ese segundo cambio en una publicación del foro de desarrolladores del 23 de noviembre de 2015 (se abre en una pestaña nueva): desde el 1 de febrero de 2016, todos los usuarios, listas y búsquedas guardadas nuevos reciben IDs Snowflake de 64 bits, los posts y los mensajes directos ya los tienen y los IDs existentes siguen siendo válidos.

Dos fechas más antiguas causan la mayor parte de la confusión. En enero de 2013, el blog de desarrolladores de Twitter anunció los IDs de usuario de 64 bits (se abre en una pestaña nueva), activados el 21 de octubre de 2013. Ese cambio solo permitió que el contador creciera más allá de 32 bits; las cuentas siguieron recibiendo IDs contados hasta 2016. Las páginas que ubican el cambio de los usuarios "hacia 2020" también se equivocan: una cuenta abierta a mediados de 2016 ya tiene un Snowflake de 18 dígitos.

• Post (tweet)

  Snowflake ID desde

  4 de noviembre de 2010

  Se decodifica a una fecha

  sí, para IDs de 15 dígitos o más

• Mensaje directo

  Snowflake ID desde

  antes de noviembre de 2015

  Se decodifica a una fecha

  sí, para IDs de 15 dígitos o más

• Cuenta de usuario

  Snowflake ID desde

  1 de febrero de 2016

  Se decodifica a una fecha

  sí para IDs de 18 y 19 dígitos, no para cuentas más antiguas

• Lista, búsqueda guardada

  Snowflake ID desde

  1 de febrero de 2016

  Se decodifica a una fecha

  sí para los IDs más nuevos y largos

• Space

  Snowflake ID desde

  nunca

  Se decodifica a una fecha

  no: los IDs de Space son letras y dígitos, como 1YqGodQbNXDxv

Para tener en cuenta

Un ID contado se decodifica sin error, y esa es la trampa. El ID de usuario de ejemplo de X, 2244994945, se convierte en el 4 de noviembre de 2010, 01:42:55 UTC, menos de un segundo después de la época, y el primer post de la historia, el ID 20, se decodifica como la propia época. Cualquier resultado en las primeras horas del 4 de noviembre de 2010 significa que el ID no contiene ninguna fecha.

Para obtener la hora de registro de una cuenta al segundo, lee created_at de la consulta de un perfil incluso cuando su ID sea un Snowflake: X no documenta en qué momento del registro asigna el ID. Sin código, el verificador de antigüedad de cuentas de Twitter gratuito muestra la fecha de registro de cualquier cuenta.

#¿Qué tan viejo es un ID? Cuenta sus dígitos

Un Snowflake ID gana un dígito cada vez que el reloj que lleva dentro cruza una potencia de diez, así que su longitud por sí sola te dice más o menos cuándo se creó. Los IDs de posts tienen 19 dígitos desde el 25 de mayo de 2018 y se mantienen en 19 hasta que el campo se agota en 2080, porque el bit superior siempre es 0.

• hasta 11

  IDs de posts

  antes del 4 de noviembre de 2010: contados, sin fecha dentro

  IDs de cuentas

  antes de febrero de 2016: contados, sin fecha dentro

• 15

  IDs de posts

  del 4 al 6 de noviembre de 2010

  IDs de cuentas

  ninguno

• 16

  IDs de posts

  del 6 de noviembre al 1 de diciembre de 2010

  IDs de cuentas

  ninguno

• 17

  IDs de posts

  del 1 de diciembre de 2010 al 7 de agosto de 2011

  IDs de cuentas

  ninguno

• 18

  IDs de posts

  del 7 de agosto de 2011 al 25 de mayo de 2018

  IDs de cuentas

  del 1 de febrero de 2016 al 25 de mayo de 2018

• 19

  IDs de posts

  desde el 25 de mayo de 2018

  IDs de cuentas

  desde el 25 de mayo de 2018

La longitud es también la razón por la que los IDs fallan en JavaScript y en las hojas de cálculo. Todo ID de post creado desde el 28 de noviembre de 2010 es mayor que 2^53, el mayor entero que un número de JavaScript guarda con exactitud, y por eso la guía de IDs de X te indica que guardes los IDs como cadenas de texto. Nuestra guía del ID de usuario de Twitter a partir del nombre de usuario muestra qué hacen Excel y JavaScript con un ID y cómo guardarlo de forma segura.

#Convierte una fecha en un ID para since_id y max_id

La fórmula funciona al revés: resta la época a una hora Unix en milésimas de segundo y desplaza el resultado 22 bits a la izquierda, y obtendrás el ID más pequeño que X pudo haber creado en ese momento. No pertenece a ningún post; marca un punto en el tiempo que la búsqueda de X entiende.

La sintaxis de búsqueda de X acepta dos marcadores así: since_id: devuelve los posts más nuevos que un ID, y max_id: devuelve los posts hasta un ID inclusive. Para la hora de 09:00 a 10:00 UTC del 14 de octubre de 2026, el límite inferior es (1791968400000 - 1288834974657) << 22, que es 2110294538449846272, y el límite superior es el ID de las 10:00 menos 1, 2110309637944246271. El POST /search-tweets (se abre en una pestaña nueva) de Sorsa API acepta la misma sintaxis:

Q="from:lanternbay_research since_id:2110294538449846272"
Q="$Q max_id:2110309637944246271"
curl -X POST "https://api.sorsa.io/v3/search-tweets" \
  -H "ApiKey: YOUR_API_KEY" \
  -H "Content-Type: application/json" \
  -d "{\"query\": \"$Q\", \"order\": \"latest\"}"

Cada página devuelve unos 20 posts con un next_cursor; envíalo de vuelta en el cuerpo hasta que regrese vacío. Guarda el ID más nuevo que tengas y pásalo como since_id: en la siguiente ejecución, y un trabajo programado nunca obtendrá el mismo post dos veces. Para segundos exactos, since_time: y until_time: aceptan segundos Unix en lugar de IDs; el resto de los operadores de fecha están en nuestra lista de operadores de búsqueda de Twitter.

#Fecha tus primeros IDs

Un Snowflake ID de Twitter se fecha a sí mismo: desplázalo 22 bits a la derecha, suma 1288834974657 y tendrás la hora de creación, a la milésima de segundo, de cualquier post desde el 4 de noviembre de 2010 y de cualquier cuenta desde febrero de 2016. Para todo lo anterior, o para poner el created_at de X junto a miles de IDs, el /tweet-info-bulk de Sorsa API lee 100 posts por solicitud desde $0.014 por 1,000, con una sola clave API y sin cuenta de desarrollador. Tus 100 solicitudes gratis fechan los primeros 10K posts, así que ejecuta el script de arriba con tu propia lista.

#Preguntas frecuentes