TwKit
正在载入
TwKit

My post log said 05:38. The tweet itself was born at 13:37. One of them was ly… · @ReignSwords · TwKit

@ReignSwords

My post log said 05:38. The tweet itself was born at 13:37. One of them was lying. It wasn't the tweet. Every X post ID is a snowflake. The top 41 bits are a millisecond timestamp, stamped at creation. Logs, schedulers, dashboards — all of them can write down the wrong time. The ID can't. I run 40 scheduled posts a day. Last week my log wrote "05:38 CST" for a post that actually went live at 13:37 CST. Eight hours off. The ID is what caught it. Here's the one-liner. Paste any tweet ID in: (id >> 22) + 1288834974657 That's the true creation time in milliseconds, UTC. 1288834974657 is X's epoch (Nov 4, 2010). Convert from there to your timezone. Two free bonuses: 1. Bigger ID = newer tweet. Always. Sort timelines without any API call. 2. An agent hands you a "last week" tweet ID that decodes to 2024? It made the ID up. Instant fabrication check. I decode IDs before I trust any timestamp my own pipeline reports. My log has lied twice. The IDs never have. Agents hallucinate tweet links constantly — should every link an agent hands you get auto-decoded before you trust it, or is that paranoid? 🔵 Fellow Premium members, let's connect! I post about AI & tech — follow for more 👥

曝光 29 · 评论 6 · 点赞 0 · 书签 0

查看原帖