Beware the natural order comparison code linked above. natcompare(10705970246197248, 9999625058521088) returns -1 incorrectly. See https://gist.github.com/727383 for an example.
On Nov 23, 12:26 pm, Matt Harris <[email protected]> wrote: > Hey everyone, > > 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: > https://api.twitter.com/1/followers/ids.json?cursor=-1&stringify_ids=1 > > 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. > > If you haven't converted your code to use the String version you should do > so immediately. Once the IDs reach 53bits Javascript, and some other > languages, misrepresent the numbers. As an example: 2**53 = 9007199254740992 > > Representing this in Javascript gives.... > > > (9007199254740992).toString() > "9007199254740992" > > (9007199254740993).toString() > "9007199254740992" > > (9007199254740994).toString() > "9007199254740994" > > (9007199254740995).toString() > "9007199254740996" > > (9007199254740999).toString() > > "9007199254741000" > > 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. > > If you are using Javascript you may find the following code samples helpful. > They were put together by our web team as an example approach to the problem > of capturing the String version of the IDs, and sorting them. > > 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. > > The second code sample using the library natcompare.js which performs > 'natural order' comparisons of strings in JavaScript. It was written by > Kristof Coomans of the SCK-CEN (Belgian Nucleair Research Centre). > http://gist.github.com/637624 > > 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: > > http://groups.google.com/group/twitter-development-talk/browse_thread... > > Best, > @themattharris > Developer Advocate, Twitter -- Twitter developer documentation and resources: http://dev.twitter.com/doc API updates via Twitter: http://twitter.com/twitterapi Issues/Enhancements Tracker: http://code.google.com/p/twitter-api/issues/list Change your membership to this group: http://groups.google.com/group/twitter-development-talk
