如何解码 Twitter Snowflake ID

#把 Snowflake ID 解码成日期

推文的创建时间就写在它的 ID 里，所以不用获取帖子就能读出来：去掉 ID 的低 22 位，加上 X 的纪元，就得到 UTC 的 Unix 时间，精确到千分之一秒，比 X 在帖子下面显示的分钟精度更细。已删除的帖子只要还有 ID 也能用，免费的推文 ID 转日期工具可以处理一个 ID，也可以处理整份列表。

1. 复制 ID。 在 x.com/<username>/status/2110301305616889042 这样的帖子链接里，ID 是 status/ 后面的数字。同一个数字也可以单独打开这条帖子，地址是 x.com/i/web/status/ 加上这个 ID。

2. 去掉低 22 位。 2110301305616889042 >> 22 等于 503135038761：这是从 X 的纪元到发帖时刻的时间，单位是千分之一秒。除以 2^22 再向下取整，结果相同。

3. 加上纪元。 503135038761 + 1288834974657 = 1791970013418，这是以千分之一秒为单位的 Unix 时间，换算成秒是 1791970013.418。

4. 读成日期。 1791970013.418 是 2026 年 10 月 14 日星期三 09:26:53.418 UTC。显示时换算成你自己的时区：X 会按每位读者的本地时区显示时间。

把任意帖子 ID、用户 ID 或帖子链接粘贴到解码器里，就能看到它的日期和四个组成部分。

下面是同样的计算，用代码实现。Python 的整数能容纳全部 64 位；在 JavaScript 里要用 BigInt，因为普通数字会把 19 位的 ID 四舍五入。

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

如果数据库把 ID 存成 64 位整数，同样的移位可以直接写在查询里：

-- 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;

这个转换工具也能一次处理一整列 ID，把结果下载成 CSV，还能把日期反过来转成 ID，全部在你的浏览器里完成。

#用 Sorsa API 查旧 ID 和长列表的日期

这套计算对两类 ID 不适用：2010 年 11 月 4 日之前的帖子，以及 2016 年 2 月之前开通的账号。它们的 ID 是依次数出来的，不含时间，所以公式算出来的时刻只比纪元晚几秒，看着合理，其实是错的。对这些 ID，以及想把 X 自己的 created_at 和解码出的时间放在一起对照时，就分批查询这些 ID。

要批量给推文 ID 查日期（包括旧 ID），用 Sorsa API，它是一款面向公开数据的 Twitter（X）API 与爬虫：POST /tweet-info-bulk 每次请求最多为 100 个帖子 ID 返回 created_at，每 1,000 条帖子 $0.014 起，官方 X API 则是每 1,000 条 $5.00。账号通过 GET /info-batch 查询，费率相同，每次 100 个，而 X 的收费是每 1,000 个 $10.00。

1. 获取密钥。 注册并从控制台复制你的 API 密钥。账号自带 100 次免费请求，无需绑卡。

2. 一次发送最多 100 个帖子 ID。 把 ID 或完整链接放进 tweet_links，发给 POST /tweet-info-bulk（在新标签页打开）；每条帖子都会完整返回，并附带作者资料。

   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"
         }
       }
     ]
   }
   

   显示完整响应

3. 用同样的方式查账号日期。 在 GET /info-batch（在新标签页打开） 中，每个账号重复一次 user_ids，最多 100 个；每份资料都带有它的 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. 只在解码帮不上忙的地方花请求。 这个脚本读取 post_ids.csv，免费解码每个 Snowflake，只把更早的 ID 发给 API，然后为每个 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"])
   

已删除或受保护的帖子不会返回，所以它那一行会留空：匹配结果要用 id，不要按位置。返回 403 表示密钥缺失或请求次数已用完，返回 429 表示你在一秒内超过了 20 次请求，失败的请求从不收费。

查询旧帖子 ID，官方 X API 每 1,000 个 $5.00，因为它对返回的每条帖子都计费；Sorsa API 则 $0.014 起，因为它按请求计费，每次请求打包 100 条帖子。

和官方 X API 相比，这项工作需要的每一方面，Sorsa API 都占优：

• 每 1,000 条帖子的价格

  Sorsa API

  $0.014 起

  官方 X API

  $5.00

• 每 1,000 个账号的价格

  Sorsa API

  $0.014 起

  官方 X API

  $10.00

• 每次请求的 ID 数

  Sorsa API

  100 条帖子或 100 个账号

  官方 X API

  100 个，逐个计费

• 2010 年 11 月之前的帖子

  Sorsa API

  支持，附带 created_at

  官方 X API

  支持，每条帖子价格相同

• 接入

  Sorsa API

  请求头里放一个 API 密钥

  官方 X API

  开发者账号、应用、bearer 令牌

• 速度

  Sorsa API

  所有套餐统一每秒 20 次请求

  官方 X API

  每 15 分钟窗口一档速率限制

• 用量

  Sorsa API

  帖子读取没有上限；用量增长可换更大的套餐

  官方 X API

  每月 300 万次帖子读取，之后是每月约 $42K 起的 Enterprise

• 你的 X 登录

  Sorsa API

  从不要求

  官方 X API

  开发者账号绑定在你的 X 账号上

官方 X API 的价格见它的价格页面（在新标签页打开）；完整对比见我们的 X API 价格指南。要获取 2006 年以来的完整时间线和搜索结果，请看 Twitter 历史数据。

#Snowflake ID 的 64 位里装了什么

Snowflake ID 是一个 64 位整数，分成四个字段：41 位时间戳、5 位数据中心编号、5 位工作节点编号和 12 位序列号，最高位始终为 0，保证数字是正数。这个布局来自 Twitter 自己的生成器，2010 年发布，保存在 snowflake-2010 源码（在新标签页打开）里，每个 ID 的构造方式是 ((time - epoch) << 22) | (datacenter << 17) | (worker << 12) | sequence。

每个字段都可以用移位和掩码读出来：

• 63

  宽度

  1

  字段

  符号位，始终为 0

  读取方式

  示例值

  0

• 62 到 22

  宽度

  41

  字段

  自纪元以来的时间，单位 1/1000 秒

  读取方式

  id >> 22

  示例值

  503135038761

• 21 到 17

  宽度

  5

  字段

  数据中心（0 到 31）

  读取方式

  (id >> 17) & 31

  示例值

  11

• 16 到 12

  宽度

  5

  字段

  工作节点（0 到 31）

  读取方式

  (id >> 12) & 31

  示例值

  7

• 11 到 0

  宽度

  12

  字段

  序列号（0 到 4,095）

  读取方式

  id & 4095

  示例值

  1234

纪元。 1288834974657 是该源文件中的常量 twepoch：2010 年 11 月 4 日星期四 01:42:54.657 UTC。Snowflake 从这个时刻起算，而不是从 1970 年起算，这样 41 位里能留出更多给未来。该字段能容纳 2^41 个千分之一秒，约 69.7 年，会在 2080 年 7 月 10 日 17:30:30.208 UTC 用完。

其余 22 位。 Twitter 2010 年的 README（在新标签页打开） 描述了 10 位机器 ID，最多 1,024 台机器，代码把它拆成数据中心和工作节点。12 位序列号用来给一台机器在同一个千分之一秒内发出的 ID 编号，最多 4,096 个。X 从未说明它现在的数据中心和工作节点编号代表什么，所以只把它们当标签，不要当数据。

顺序。 因为时间位于最高位，ID 越大几乎总是意味着帖子越新。README 承诺跨机器的顺序大约精确到一秒，X 的 ID 指南（在新标签页打开）也因此称 ID 大致按时间排序：不同机器上同一秒发出的两条帖子，ID 顺序可能是反的。

其他平台照搬了这套设计，但用的是各自的纪元，所以拿 X 的纪元去解码别的服务的 ID，得到的日期会差好几年。

#哪些 X ID 是 Snowflake，从什么时候开始

帖子 ID 从 2010 年 11 月 4 日起成为 Snowflake；用户、列表和已保存搜索的 ID 从 2016 年 2 月 1 日起跟进。X 在 2015 年 11 月 23 日的开发者论坛帖子（在新标签页打开）里自己宣布了第二次切换：从 2016 年 2 月 1 日起，所有新用户、列表和已保存搜索都使用 64 位 Snowflake ID，帖子和私信已经是了，现有 ID 仍然有效。

有两个更早的日期造成了大多数混淆。2013 年 1 月，Twitter 开发者博客宣布了 64 位用户 ID（在新标签页打开），并于 2013 年 10 月 21 日启用。那次改动只是让计数器可以超过 32 位；账号直到 2016 年仍然拿到依次计数的 ID。有些页面把用户切换的时间说成“2020 年前后”，同样不对：2016 年年中开通的账号已经是 18 位的 Snowflake 了。

• 帖子（推文）

  从何时起使用 Snowflake ID

  2010 年 11 月 4 日

  能否解码出日期

  能，适用于 15 位及以上的 ID

• 私信

  从何时起使用 Snowflake ID

  2015 年 11 月之前

  能否解码出日期

  能，适用于 15 位及以上的 ID

• 用户账号

  从何时起使用 Snowflake ID

  2016 年 2 月 1 日

  能否解码出日期

  18 位和 19 位的 ID 能，更早的账号不能

• 列表、已保存搜索

  从何时起使用 Snowflake ID

  2016 年 2 月 1 日

  能否解码出日期

  较新的、更长的 ID 能

• Space

  从何时起使用 Snowflake ID

  从未使用

  能否解码出日期

  不能：Space ID 是字母和数字，如 1YqGodQbNXDxv

须知

依次计数的 ID 解码时不会报错，这正是陷阱。X 自己示例里的用户 ID 2244994945，会被解成 2010 年 11 月 4 日 01:42:55 UTC，比纪元只晚不到一秒；第一条帖子 ID 20 解码出来就是纪元本身。任何落在 2010 年 11 月 4 日最初几小时内的结果，都说明这个 ID 里没有日期。

要得到账号精确到秒的注册时间，即使它的 ID 是 Snowflake，也请从资料查询里读取 created_at：X 没有说明注册过程中是在哪一刻给 ID 盖上时间的。不写代码的话，免费的 Twitter 账号注册时间查询能显示任意账号的加入日期。

#ID 有多老？数一数位数

Snowflake ID 里的时钟每越过一个 10 的幂，ID 就多一位，所以光看长度就能大致知道它是什么时候生成的。帖子 ID 从 2018 年 5 月 25 日起一直是 19 位，直到 2080 年该字段用完都保持 19 位，因为最高位始终是 0。

• 最多 11 位

  帖子 ID

  2010 年 11 月 4 日之前：依次计数，里面没有日期

  账号 ID

  2016 年 2 月之前：依次计数，里面没有日期

• 15

  帖子 ID

  2010 年 11 月 4 日到 6 日

  账号 ID

  无

• 16

  帖子 ID

  2010 年 11 月 6 日到 12 月 1 日

  账号 ID

  无

• 17

  帖子 ID

  2010 年 12 月 1 日到 2011 年 8 月 7 日

  账号 ID

  无

• 18

  帖子 ID

  2011 年 8 月 7 日到 2018 年 5 月 25 日

  账号 ID

  2016 年 2 月 1 日到 2018 年 5 月 25 日

• 19

  帖子 ID

  2018 年 5 月 25 日起

  账号 ID

  2018 年 5 月 25 日起

长度也是 ID 在 JavaScript 和电子表格里出错的原因。2010 年 11 月 28 日以来生成的每个帖子 ID 都大于 2^53，也就是 JavaScript 数字能精确表示的最大整数，这就是 X 的 ID 指南让你把 ID 当字符串保存的原因。我们的用用户名查 Twitter 用户 ID指南展示了 Excel 和 JavaScript 会怎样破坏 ID，以及怎样安全地保存。

#把日期转成 ID，用于 since_id 和 max_id

公式可以倒过来用：从以千分之一秒为单位的 Unix 时间里减去纪元，再把结果左移 22 位，就得到 X 在那一刻可能生成的最小 ID。它不属于任何帖子，只是一个 X 搜索能识别的时间点标记。

X 的搜索语法接受两种这样的标记：since_id: 返回比某个 ID 更新的帖子，max_id: 返回不超过某个 ID 的帖子。对于 2026 年 10 月 14 日 UTC 09:00 到 10:00 这一小时，下界是 (1791968400000 - 1288834974657) << 22，即 2110294538449846272，上界是 10:00 对应的 ID 减 1，即 2110309637944246271。Sorsa API 的 POST /search-tweets（在新标签页打开） 接受同样的语法：

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\"}"

每页返回约 20 条帖子，并带一个 next_cursor；把它放回请求体再发，直到返回为空。保存你已有的最新 ID，下次运行时把它作为 since_id: 传入，定时任务就不会重复获取同一条帖子。要精确到整秒，可以用 since_time: 和 until_time:，它们接受 Unix 秒而不是 ID；其余的日期运算符见我们的 Twitter 搜索运算符列表。

#给你的第一批 ID 查日期

Twitter Snowflake ID 自带日期：右移 22 位，加上 1288834974657，就得到创建时间，精确到千分之一秒，适用于 2010 年 11 月 4 日以来的任何帖子和 2016 年 2 月以来的任何账号。对更早的 ID，或者想把 X 自己的 created_at 放在成千上万个 ID 旁边对照，Sorsa API 的 /tweet-info-bulk 每次请求读取 100 条帖子，每 1,000 条 $0.014 起，只需一个 API 密钥，不需要开发者账号。你的 100 次免费请求可以查完前 1 万条帖子的日期，所以用上面的脚本跑一遍你自己的列表吧。

#常见问题