Twitter IDs to roll past 53 bits in a couple days (may break javascript apps)
1–10 of 48 posts
Re: Twitter IDs to roll past 53 bits in a couple days (may break javascript apps)
#2When the first 32-bit troubles occurred, they should have just switched to a string-based ID, IMO.
Re: Twitter IDs to roll past 53 bits in a couple days (may break javascript apps)
#3When the first 32-bit troubles occurred, they should have just switched to a string-based ID, IMO.
That was my first thought... who on earth thought that a number (albeit 64-bit) would be enough for Twitter? Who even thought that a 32bit int would have been enough?
I didn't know that Javascript couldn't handle numbers bigger than 53-bits, but honestly, these should have been strings from the beginning.
Re: Twitter IDs to roll past 53 bits in a couple days (may break javascript apps)
#4JavaScript apps have been broken for a couple weeks now with links to things like:
Re: Twitter IDs to roll past 53 bits in a couple days (may break javascript apps)
#5Re: Twitter IDs to roll past 53 bits in a couple days (may break javascript apps)
#6When the first 32-bit troubles occurred, they should have just switched to a string-based ID, IMO.
To be fair, 2^64 is a whole ton huger than 2^32 and they might not have been thinking about whether JavaScript could handle the identifiers (one normally assumes these days that programming languages have native support for 64-bit ints).
Re: Twitter IDs to roll past 53 bits in a couple days (may break javascript apps)
#7When the first 32-bit troubles occurred, they should have just switched to a string-based ID, IMO.
That was my first thought... who on earth thought that a number (albeit 64-bit) would be enough for Twitter? Who even thought that a 32bit int would have been enough? I didn't know that Javascript couldn't handle numbers bigger than 53-bits, but honestly, these should have been strings from the beginning.
I didn't know that Javascript couldn't handle numbers bigger than 53-bits
The JavaScript Number type can't handle more precision than 53 bits. Magnitude is orthogonal due to floating-point representation. Precision is governed by the size of the mantissa, which is 52+1 bits long in the 64-bit IEEE 754 representation used by JavaScript.
Re: Twitter IDs to roll past 53 bits in a couple days (may break javascript apps)
#8My rule of thumb is to use strings for all IDs that belong to external systems. A bunch of people got burned in the same way a few years ago when Flickr photo IDs rolled past 32 bits.
Re: Twitter IDs to roll past 53 bits in a couple days (may break javascript apps)
#9When the first 32-bit troubles occurred, they should have just switched to a string-based ID, IMO.
Agreed. And also, there's not a lot of manipulation/math to be done on these IDs once they come back to the client. They're only used again when an operation happens on a tweet (favoriting it, replying to it) and in that case you're just taking the ID and sending it back to Twitter.
Re: Twitter IDs to roll past 53 bits in a couple days (may break javascript apps)
#10When the first 32-bit troubles occurred, they should have just switched to a string-based ID, IMO.
Agreed. And also, there's not a lot of manipulation/math to be done on these IDs once they come back to the client. They're only used again when an operation happens on a tweet (favoriting it, replying to it) and in that case you're just taking the ID and sending it back to Twitter.
not really.
You (can) use since_id and max_id in many places, which means you need them to be ordered (and trivially so).
This is of course doable with strings too, once you decide what the ordering is.