parseInt("220125152409071002")
220125152409071000

Looks good... looks good... looks good... wait wtf?!? where the hell is the 2?!?!

Can confirm. WTF

Here....... 2.
Sorry! Needed it for a bit.

Okay, hear me out.. I don’t know either.

Value is above max int precision, JS uses floating point numbers to store integers (it's lying to you), so what you're seeing is float quantization, I think.

Just read about Number.MAX_SAFE_INTEGER and it references something called BigInt.

https://developer.mozilla.org/en-US...

Edit: You just too big. (TWSS)

And that is why we don't do javascript.

Please tell me that you don't use this format as a timestamp.

@happygimp0 what's wrong with ignoring the 30 compliant standards and making one up on your own?

That's what being a node dev is all about... Making shit up and turning it into a npm package!

@happygimp0 haha, they are transaction IDs - from the API docs they are officially int64 which is fine for "real" languages... but... I guess I'll have to be happy with just string client-side lol

@saucyatom other languages do this, too.

E.g. MySQL - to stay architecture independent. BigInt with float fuckery to represent a 64 bit integer

@atheist I assumed something like that was going on... I know there are libraries for handling this "feature" of the language, but no idea how reliable they are. I remember yelling at someone a few days ago on here because they wanted to do something like orbital calculations in javascript.... this is a great example of one of those glaring reasons why you wouldn't want to do that :)

@fullstackchris thing is, you'll get the same result in a lot of languages, floating point numbers have 2^53 bits of precision or something. Even c, default ints are 32 bits of precision, longs 64. For orbital mechanics, that's probably enough for 2 body calculations, 3 body problem is chaotic anyway so you'll get weirdness for exact calculations.

@Demolishun "You just too big", said no girl to me ever :/

@tman540 My condolences.

@atheist No. A int in C is not 32 per default nor a long 64 bit. Standard says a int should have at least 15 value bits and 1 sign bit (that is implied for the minimum rang of -32767 [sic] to +32767), a long has at minimum 31+1 bit. If you want a 32 bit integer use uint32_t or int32_t, other options that are at least 32 bit are uint_fast32_t, int_fast32_t, , uint_least32_t, int_least32_t, long, unsigned long.

There are similar types for 64 bit, or you can use long long which is at least 64 bit.

Do not assume a int has more than 16 bit. On halve of the architectures which i programmed for used 16 bit ints.

@happygimp0 by default on most modern systems. My point was more around "other languages have finite precision", but you're right the standard doesn't guarantee the precision I listed.

Close eeeeenough!

@jeeper haha, select from data where id = ... shit where did it go!?!?

Sometimes I wish SQL had a "close enough" function 😂