3 ms·
> Javascript applications are going to be doing this naturally Only because its timestamp (as in `Date.getTime`) is actually the number of milliseconds since t
by 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 agoI 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.