3 ms·

You're both making too much of this. I mean, Javascript applications are going to be doing this naturally, have been for decades now, and... it's fine. Floati

by ajross 3y ago

You're both making too much of this. I mean, Javascript applications are going to be doing this naturally, have been for decades now, and... it's fine. Floating point can indeed be a footgun, but generally not in the space of single numbers like this. And integer representations have traps too. To pick on your particular example: "timestamps" are not the same thing as "times" and if your code predicated on that, it likely has bugs already with monotonicity and uniqueness assumptions. And the benefit is that, as the article points out, you can have easy subsecond precision, something that is much harder (and pervasively unsupported by existing libraries) with fixed point math. Should one go to the mattresses to defend either of these designs? No. But on the whole my heart agrees with the linked article. If you have to make a choice today, for new code, stick with a double.

lifthrasiir 3y ago
> Javascript applications are going to be doing this naturally Only because its timestamp (as in `Date.getTime`) is actually the number of milliseconds since the UNIX epoch assuming no leap seconds. You can't keep the current scheme in a nanosecond precision (2^31 * 10^9 ~= 2^61, so float64 will truncate lower bits). Python had the exact same issue and it now has a separate `time.time_ns()` function as opposed to the traditional `time.time()` function.
- ajross 3y ago
  > You can't keep the current scheme in a nanosecond precision (2^31 * 10^9 ~= 2^61, so float64 will truncate lower bits). What integer system do you expect to work well with nanosecond time values? As you just showed, a 64 bit ns value will rollover in O(2^32) seconds, which is already universally considered to be insufficient for an epoch time. Again, this is splitting hairs. In fact as I see it doubles would be preferable in in that regime, as while you'll be dancing at the edge of their representation capability, they at least won't blow trying to record dates in the 1420's or whatever. You can get as close as is practical without worrying about representation space.
  - lifthrasiir 3y ago
    I mean, you are not really wrong, but I disagree doubles may be "preferable". It's like using integers for telephone numbers, which may work for many (or depending countries, most) inputs and you can justify that, but I would never accept it.

by ajross 3y ago

lifthrasiir 3y ago

> Javascript applications are going to be doing this naturally Only because its timestamp (as in `Date.getTime`) is actually the number of milliseconds since the UNIX epoch assuming no leap seconds. You can't keep the current scheme in a nanosecond precision (2^31 * 10^9 ~= 2^61, so float64 will truncate lower bits). Python had the exact same issue and it now has a separate `time.time_ns()` function as opposed to the traditional `time.time()` function.

ajross 3y ago
> You can't keep the current scheme in a nanosecond precision (2^31 * 10^9 ~= 2^61, so float64 will truncate lower bits). What integer system do you expect to work well with nanosecond time values? As you just showed, a 64 bit ns value will rollover in O(2^32) seconds, which is already universally considered to be insufficient for an epoch time. Again, this is splitting hairs. In fact as I see it doubles would be preferable in in that regime, as while you'll be dancing at the edge of their representation capability, they at least won't blow trying to record dates in the 1420's or whatever. You can get as close as is practical without worrying about representation space.
- lifthrasiir 3y ago
  I mean, you are not really wrong, but I disagree doubles may be "preferable". It's like using integers for telephone numbers, which may work for many (or depending countries, most) inputs and you can justify that, but I would never accept it.