|Snowflake, it's almost 9007199254740992 time.||Matt Harris||11/23/10 9:26 AM|
You may remember a few weeks ago we launched Snowflake having encouraged you all to check your code to make sure you were able to handle the larger numbers it will generate. For those of you whose code couldn't handle the longer numbers we created String versions of the IDs in our JSON responses, identified by an "_str" at the end of their name - for example the Tweet ID in the JSON response exists twice: once as a number (id) and once as a string (id_str). For API requests which returned arrays of IDs we added the parameter "stringify_ids" to force all IDs to Strings. For example:
We're sending this reminder because at 2.14pm PDT (10.14pm UTC) this Sunday, 28th November 2010 Snowflake IDs will reach 53bits.
Only Tweet IDs are generated by Snowflake. This means only Tweets, Retweets, Mentions and Replies are affected this weekend. Things like Saved Searches, Users and Direct Messages are not Snowflaked.
You can see in this example that the Tweet IDs are being misrepresented in their converted state. We've provided String versions of all of our IDs, even those which are not using Snowflake IDs. We've done this to make it easier for you to convert your code. Even if your code can handle the longer numbers you may want to convert to Strings anyway. Doing so will reduce the risk of problems should you extend your code with a language or library that doesn't support >53bit numbers.
The first gist looks for the new *_str field and uses it if it's there. If it's missing, the original field is used but stringified first. This doesn't make IDs >53bit safe for you but but does mean you can use String IDs for all other attributes without having to check for them first.
There has been some great discussion about this in the developer forums, including some questions and answers about the change. You can read more here:
Developer Advocate, Twitter