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 :)