5 ms·

I strongly disagree with this. It only makes sense to use floats if you want time to have increasing precision the closer you get to 1970. From a symmetry group

I strongly disagree with this. It only makes sense to use floats if you want time to have increasing precision the closer you get to 1970. From a symmetry group perspective, that makes no sense; the amount you care about the incremental precision of time measurement is invariant with respect to the present date. (Translation invariance). This means you want uniformly distributed time samples, hence an integer format. If you think microsecond precision is good enough for anybody, then you could consider using an integer where the LSB represents 1 microsecond. But don't use floating point time, unless your specific application cares more about time scale invariance than time translation invariance.

dheera 3y ago
You can even go to nanosecond. The largest uint64 is 18446744073709551615 and epoch time now in nanoseconds is less than a tenth of that i.e. 1686340765688397824 You can go for another 500+ years safely on nanoseconds-as-uint64. I fully disagree with using float64. It wastes bits on an exponent and you cannot safely use == to compare timestamps that have math done on them or have been converted to/from a string (including e.g. sent as part of a JSON).
- lordnacho 3y ago
  Me too. I thought it was normal already to just store the unix nanos. At least that's what I do and it seems to work. Yes I have stuff with nano granularity. You don't want to get into floating point, it gets all fuzzy and then when you need to change it, there's a bunch of code to change.
- johnea 3y ago
  The article fails to mention the earliest standard addressing this issue, DJB's taitime: https://cr.yp.to/proto/utctai.html https://cr.yp.to/proto/utctai.html
- deadmutex 3y ago
  int64 to represent times before 1970, and to make it easier to do time diffs (since subtracting two uint64s in C++ can cause overflow)
- 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

dheera 3y ago

You can even go to nanosecond. The largest uint64 is 18446744073709551615 and epoch time now in nanoseconds is less than a tenth of that i.e. 1686340765688397824 You can go for another 500+ years safely on nanoseconds-as-uint64. I fully disagree with using float64. It wastes bits on an exponent and you cannot safely use == to compare timestamps that have math done on them or have been converted to/from a string (including e.g. sent as part of a JSON).

lordnacho 3y ago
Me too. I thought it was normal already to just store the unix nanos. At least that's what I do and it seems to work. Yes I have stuff with nano granularity. You don't want to get into floating point, it gets all fuzzy and then when you need to change it, there's a bunch of code to change.
johnea 3y ago
The article fails to mention the earliest standard addressing this issue, DJB's taitime: https://cr.yp.to/proto/utctai.html https://cr.yp.to/proto/utctai.html
deadmutex 3y ago
int64 to represent times before 1970, and to make it easier to do time diffs (since subtracting two uint64s in C++ can cause overflow)
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