jq is rounding 64-bit unsigned integers

[arjones]

Twitter statuses (tweets) ids are implemented as 64-bit unsigned integers (more on the implementation here).

When I parse the id field jq is showing a different rounded number. For convenience, Twitter guys implemented a field id_str been a string it doesn't suffer from the same behavior, and contains the desired value.

AFIK, this problem didn't happened before (I'm been using JQ for several years now), so I believe it can be related to the increasing ID value on tweets may be responsible for it.

I'm leaving a sample file which contains 30 tweets where you can compare both fields: statuses-sample.txt

jq -c '{id, id_str}' < statuses-sample.json

{"id":675127116845989900,"id_str":"675127116845989888"}
{"id":675083374680268800,"id_str":"675083374680268800"}
{"id":674990359378829300,"id_str":"674990359378829312"}
{"id":674452469880107000,"id_str":"674452469880107008"}
{"id":674294161479200800,"id_str":"674294161479200769"}
{"id":673883175165304800,"id_str":"673883175165304832"}
{"id":673537658702970900,"id_str":"673537658702970880"}
{"id":673354456264781800,"id_str":"673354456264781824"}
{"id":672818961126465500,"id_str":"672818961126465536"}
{"id":672773809674575900,"id_str":"672773809674575874"}
{"id":672046221935157200,"id_str":"672046221935157248"}
{"id":671163742961451000,"id_str":"671163742961451008"}
{"id":671044052582801400,"id_str":"671044052582801410"}
{"id":670793705918480400,"id_str":"670793705918480384"}
{"id":670444042199650300,"id_str":"670444042199650304"}
{"id":669659081343389700,"id_str":"669659081343389696"}
{"id":669334595486224400,"id_str":"669334595486224388"}
{"id":668554615487639600,"id_str":"668554615487639552"}
{"id":667900678761746400,"id_str":"667900678761746432"}
{"id":667156219891683300,"id_str":"667156219891683328"}
{"id":666022963637035000,"id_str":"666022963637035008"}
{"id":665936961228693500,"id_str":"665936961228693504"}
{"id":665592696229244900,"id_str":"665592696229244928"}
{"id":665140764792496100,"id_str":"665140764792496128"}
{"id":664671743555039200,"id_str":"664671743555039232"}
{"id":664189957834174500,"id_str":"664189957834174465"}
{"id":664052344603193300,"id_str":"664052344603193345"}
{"id":663167030946889700,"id_str":"663167030946889728"}
{"id":661623563837907000,"id_str":"661623563837906944"}
{"id":659312810288132100,"id_str":"659312810288132096"}

[nicowilliams]

See #1387 (comment).

This is often reported. (see also #545, #529, and #178)

The summary here is that it's not a bug. Internally, we use IEEE754 doubles, and those can't perfectly represent all integers, especially not all large ones. We have a feature we're working on (#1327) that will somewhat improve this behavior.

Closing as a duplicate.