Investigate the use of BigInt or as string in the TSP

[tahini]

• Sending "long" times using JSON number is a potential problem to any javascript or any language that doesn't support big integer. It will work in Theia if we use BigInt, but not in other frontend if the dev doesn't or can't support BigInt.
• Sending as string might impact the size or the response but need to test if it really does something. The advantage is that the frontend can convert that string in something that can be useful
• We can either force BigInt in TSP or use String
• NodeJS 10 and Chrome supports it, (JavaScript version?)
• Time Graph library uses currently offset scheme

[haoadoreorange]

I forgot that there is an issue for this. A bit update to the current state.

The JSON format itself supports BigInt. However, the JSON.parse spec of JS can't parse those value (it loses precision). I retraced some old TC39 proposal but it seems dead. I decided going for a custom parser.

By searching around I find the package json-bigint the most suitable, the package itself was inspired by the original JSON now part of V8. I made a PR with some changes and optimization. Benmarking results a ~4x slower than the default parser, which is pretty optimized among custom parsers afaik. The PR is now merged and published on npm.

Where do we go from here ?

[MatthewKhouzam]

Maybe we can look into this: https://www.npmjs.com/package/timestamp-nano

[ebugden]

Closing since resolved by PR #485.

Utility of this fix: My understanding was not having BigInt precision on timestamps was making selection inaccurate. MatthewKhouzam: "we could not seek accurately without that patch. you would have 512 ns errors on your clicks"