Cannot Parse m_timeUTC and m_timeLocalOffset about heroprotocoljs HOT 3 CLOSED

jnovack commented on August 24, 2024

Cannot Parse m_timeUTC and m_timeLocalOffset

from heroprotocoljs.

Comments (3)

jnovack commented on August 24, 2024

Node seems to be able to handle it. It's probably something in the coding.. time to dive. :/

$ node
> s = 130990020780514880;
130990020780514880
> o = { s: 130990020780514880 }
{ s: 130990020780514880 }
> new Date(s / 10000 - 11644473600000);
Wed Feb 03 2016 14:41:18 GMT-0500 (EST)
> new Date(o.s / 10000 - 11644473600000);
Wed Feb 03 2016 14:41:18 GMT-0500 (EST)
> console.log(s);
130990020780514880
undefined
> console.log(o.s);
130990020780514880
undefined
> console.log(o);
{ s: 130990020780514880 }
undefined
> console.log(JSON.stringify(o));
{"s":130990020780514880}
undefined
> JSON.parse(JSON.stringify(o));
{ s: 130990020780514880 }
> j = JSON.parse(JSON.stringify(o));
{ s: 130990020780514880 }
> j
{ s: 130990020780514880 }
> new Date(j.s / 10000 - 11644473600000);
Wed Feb 03 2016 14:41:18 GMT-0500 (EST)

from heroprotocoljs.

jnovack commented on August 24, 2024

The number is passing through VersionDecoder.prototype._vint in decoders.js, my guess is incorrectly, despite the function being exactly the same as the python version.

Python 2 (I have ZERO experience in Python) says "int" is a signed 32-bit, so that doesn't make much sense that it's a 64-bit number, unless Python does some magic that auto-converts it.

It looks like the VersionDecoder.prototype._vint function in decoders.js will need a shim.

from heroprotocoljs.

jnovack commented on August 24, 2024

Fix is in jnovack/heroprotocoljs#long branch and can be applied once #37 is accepted.

from heroprotocoljs.

Recommend Projects