Twitter is famous for pioneering the snowflake ID, which is now used by many large-scale distributed services.
Given a snowflake ID, online tools such as TweetedAt allow you to extract the timestamp from it.
It is reasonable to assume that the timestamps obtained this way should match the created_at
metadata obtained through Twitter’s API endpoints. However, this is not always the case.
Tweet snowflake ID vs create_at
I used the snowflake IDs of my own tweets to test whether the created_at
timestamp returned by the API matches the rounded Unix timestamp extracted from the ID (using Python’s int()
, which always rounds down).
The result: a 100% match!
User snowflake ID vs created_at
Not every Twitter user has a snowflake ID
In the beginning, Twitter’s user IDs were 32-bit integers. Then in 2013, in fear of running out of 32-bit IDs in the distant future, Twitter upgraded the user IDs to 64-bit integers.
Although Twitter had already been using 64-bit snowflake IDs for tweets since 2010, the 2013 user ID upgrade curiously did not adopt this system for user IDs.
After some investigation, I believe that Twitter’s transition from old-style user IDs to snowflake user IDs occurred between 2016-02-16
and 2016-02-17
. This was a chaotic time, as some users who registered their accounts during this period were assigned old-style IDs, while others received brand-new snowflake IDs.
user rest_id | snowflake? | created_at |
---|---|---|
699570924048162816 | true | 2016-02-16T12:28:00+00:00 |
699757151795990528 | true | 2016-02-17T00:48:00+00:00 |
4922450361 | false | 2016-02-17T05:07:17+00:00 |
4923106354 | false | 2016-02-17T08:36:46+00:00 |
4924072528 | false | 2016-02-17T14:31:17+00:00 |
Twitter changed how user created_at
is generated
Based on our experience with tweets, we would expect that the created_at
timestamp for users should match the timestamps extracted from the user snowflake IDs.
This is more or less true for users created before 2019-08-16
, but no longer holds for users created after that date.
By the way, the rounding direction of the unix timestamp extracted from the snowflake user ID is inconsistent, especially for fractions in the [0.83,0.86]
range.
Here are a few examples of users created before 2019-08-16
:
user rest_id | created_at | snowflake timestamp |
---|---|---|
753883559681724416 | 2016-07-15T09:27:01+00:00 | 2016-07-15T09:27:01+00:00 |
822768028102238212 | 2017-01-21T11:29:18+00:00 | 2017-01-21T11:29:18+00:00 |
907077292446203904 | 2017-09-11T03:04:13+00:00 | 2017-09-11T03:04:13+00:00 |
965231053119148032 | 2018-02-18T14:26:30+00:00 | 2018-02-18T14:26:30+00:00 |
1085820630899937280 | 2019-01-17T08:46:26+00:00 | 2019-01-17T08:46:26+00:00 |
1162006325607485440 | 2019-08-15T14:21:11+00:00 | 2019-08-15T14:21:11+00:00 |
After 2019-08-16
, the created_at
timestamp no longer matches the timestamp extracted from the snowflake ID. Instead, created_at
is always later than the snowflake ID timestamp. The delay is usually from a few seconds to a couple of seconds, but there is a long tail in the distribution, meaning that sometimes the delay can be over 2 hours!
Here are a few examples of users created after 2019-08-16
:
user rest_id | created_at | snowflake timestamp | delay |
---|---|---|---|
1162390352621293569 | 2019-08-16T15:47:32+00:00 | 2019-08-16T15:47:10+00:00 | 22s |
1177555721375772672 | 2019-09-27T12:10:36+00:00 | 2019-09-27T12:08:56+00:00 | 100s |
1397699172355088387 | 2021-05-26T23:44:51+00:00 | 2021-05-26T 23:40:25+00:00 | 266s |
1366715223055368192 | 2021-03-02T11:58:52+00:00 | 2021-03-02T11:41:16+00:00 | 1056s |
1477262476479586304 | 2022-01-01T15:03:02+00:00 | 2022-01-01T12:56:35+00:00 | 7587s |
The source of the delay?
No action you take on the account creation interface will change the amount of delay. The delay appears to be due to internal processing that occurs on Twitter’s servers. It seems that created_at
is the moment when everything is settled down for a new user.
User experience implications
I’m now curious about the experience of users who have super long delay between snowflake ID creation and the finalization of the account creation process. With some experiments, it occurs to me that the snowflake ID is created when you submit the verification code for your new account. If there is an hour long delay, does that mean you have to wait until then to be able to perform any user actions on your new account? Will you receive any feedback on the situation? Only the selected few who are unfortunate enough to go through the weird situation will know the answer :)