Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

They didn't roll over, they exceeded 2^53-1 which is the max Number which doesn't truncate when treated as an integer in js. The solution was to treat it as a string.

(Or we're thinking of different events, I apologize if so)



Twitter must have been misleading when they communicated the reasons for this change since they did not exceed 2^53-1, nor do they expect to exceed this in the near future.

From a (former) Twitter dev:

> Given the current allocation rate, they'll probably never overflow Javascript's precision nor get anywhere near the 64-bit integer space.

https://twittercommunity.com/t/discussion-for-moving-to-64-b...


Your link discusses 2^64, which applies to languages that have native integer types.

The 2^53 problem was for Javascript, which has no native integer type, and is thus limited by the mantissa size of Number (which is defined as an IEEE double-precision float).

Twitter ids are unsigned 64-bit, since they're generated using Snowflake. That link must pre-date the move to snowflake ids, and is speaking to the count of tweets instead.


I'd be incredibly surprised if they overflowed 9 quadrillion tweets. That's like a million tweets per person on earth.


Haha, sorry, that thought was in reference to the link saying they hadn't overflowed 2^31 yet. Two billion seems believable for tweets as of 2013.


In the dystopian future where everyone's IoT devices communicate by tweeting at each other this might become a real issue.


Its the retweets, dude. /s

On a more serious side, that number won't be reached anytime soon..


Rollover was a confusing word for me to use. I did not mean it in terms of integer overflow. I meant it in accounting terms. As in to roll from one namespace to another.

I could have definitely chosen my words better.


Yep, it would just point to the wrong tweet. Fun stuff. So many of these time bombs.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: