tiktok · when was this JD uploaded?
Paste a lifeattiktok.com URL or a 19-digit URL ID — get the estimated post time.
▸
—
RECORDS0
| URL ID | TITLE | PT date | posted |
|---|
SNOWFLAKE MATH// how this is computed
01
URL ID is a Snowflake-style 64-bit integer
┌──────┬────────────────────────┬──────────┬──────────┐
│ 1 b │ ~41 bits timestamp │ ~10 bits │ ~12 bits │
│ sign │ (ms) │ machine │ sequence │
└──────┴────────────────────────┴──────────┴──────────┘
└─────── 22 bits ─────┘
(drop via >> 22)
The lower 22 bits identify which server and which sequence number
generated the ID — noise to us. We only want the timestamp, so we right-shift them off:
id >> 22.
02
ByteDance's epoch is private — so we calibrate
Twitter's Snowflake uses
2010-11-04 as epoch. ByteDance picked a different
anchor and never published it, so the raw timestamp bits are an opaque counter. The fix:
anchor to one ID whose true post time is already known, then express every other
ID relative to it.
REFERENCE_ID =
REFERENCE_TIME = 2026-05-14 03:18 PT (= 2026-05-14 10:18 UTC)
03
Decoding any other ID is just subtraction
ms_diff = (REFERENCE_ID − target_id) >> 22 posted_utc = REFERENCE_TIME − ms_diff (in milliseconds)
The same 22-bit shift kills the noise from both IDs symmetrically — what's left
is purely a duration in milliseconds.
04
Worked example with target_id =
raw_diff = REFERENCE_ID − target_id
= 7634297575580092677 −
=
ms_diff = raw_diff >> 22 (2^22 = 4,194,304)
= ms
≈ days
posted = 2026-04-30 10:00 UTC − days
= UTC
= PT
↑ Compare against the row in records above — it's the same number arrived at the same way.
!
caveat. The 22-bit split is inferred from Twitter's Snowflake — ByteDance
may use a slightly different layout. ±10–20% drift on the timestamp window is plausible.
Day-level estimates hold up; hour/minute precision shouldn't be trusted. If ByteDance
rotates their ID scheme, the calibration breaks and everything reads as the future or
ancient past — that's the signal to pick a fresh reference.