21

parseInt("220125152409071002")
220125152409071000

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

Comments
  • 4
    Can confirm. WTF
  • 6
    Okay, hear me out.. I don’t know either.
  • 19
    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.
  • 9
    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)
  • 3
    And that is why we don't do javascript.
  • 12
    Please tell me that you don't use this format as a timestamp.
  • 9
    @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!
  • 2
    @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
  • 3
    @saucyatom other languages do this, too.

    E.g. MySQL - to stay architecture independent. BigInt with float fuckery to represent a 64 bit integer
  • 2
    @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 :)
  • 3
    @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.
  • 1
    @Demolishun "You just too big", said no girl to me ever :/
  • 0
    @tman540 My condolences.
  • 0
    @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.
  • 0
    @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.
  • 0
    Close eeeeenough!
  • 0
    @jeeper haha, select from data where id = ... shit where did it go!?!?

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