6 ms·

High resolution timestamps relative to 1970-01-01T00:00:00

pacman128 6y ago
The trick I've seen to deal with this problem is to use a pair of doubles: one for the integer part and one for the fractional part.
- diffuse_l 6y ago
  Isn't it simpler to use fixed point in this case?
- vnorilo 6y ago
  You can use double-doubles for near-128-bit floating point [1]. It's much more powerful than 53.53 fixed point you mentioned, but more complicated as well. [1] http://web.mit.edu/tabbott/Public/quaddouble-debian/qd-2.3.4-old/docs/qd.pdf http://web.mit.edu/tabbott/Public/quaddouble-debian/qd-2.3.4...
AnotherGoodName 6y ago
Calculating the heat death of the universe down to the nanosecond are we? (i mean this is a legitimate reason, it's just amusing the extremes you'd have to go to to break 64bits).
- pavon 6y ago
  I know it is a joke, but 64bit fixed-point representation with nanosecond resolution has just ~585 years of range. With 1e100 years of range needed to measure out to the heat-death of the universe, you end up with resolution of ~5e80 years, which is 60 orders of magnitude longer than the current age of the universe. It is easy to run out of bits when trying to use a single number as both an absolute date/time, and to compute relative durations between timestamps with reasonable precision. I've lost track of the number of bugs I've fixed where someone assumed a double would be big enough without doing the math.
- 3JPLW 6y ago
  Hunh? January 1, 1970 + 9.007199254740992e15 nanoseconds gets you all the way to... tax day[1]. Microseconds gets you to the year 2255; milliseconds to heat death. 1. https://www.wolframalpha.com/input/?i=January+1%2C+1970+%2B+9.007199254740992e15+nanoseconds https://www.wolframalpha.com/input/?i=January+1%2C+1970+%2B+...
  - pavon 6y ago
    Qwibble: Microseconds gets you to the year 2540 with double precision, because the implied 1-bit means you effectively have 54-bit mantissa.
fanf2 6y ago
Yes, 64 bits is not really comfortable for a long-term timestamp format. The NTP nanokernel uses a 64.64 integer represention https://papers.freebsd.org/2000/phk-nanokernel/ https://papers.freebsd.org/2000/phk-nanokernel/ because 32 bits isn't enough above the binary point because it runs out in 2038, and below the binary point you need 64 bits to accurately represent the nanosecond-scale frequency of the CPU's cycle counter to translate it to wall-clock time.

The trick I've seen to deal with this problem is to use a pair of doubles: one for the integer part and one for the fractional part.

diffuse_l 6y ago
Isn't it simpler to use fixed point in this case?
vnorilo 6y ago
You can use double-doubles for near-128-bit floating point [1]. It's much more powerful than 53.53 fixed point you mentioned, but more complicated as well. [1] http://web.mit.edu/tabbott/Public/quaddouble-debian/qd-2.3.4-old/docs/qd.pdf http://web.mit.edu/tabbott/Public/quaddouble-debian/qd-2.3.4...

AnotherGoodName 6y ago

Calculating the heat death of the universe down to the nanosecond are we? (i mean this is a legitimate reason, it's just amusing the extremes you'd have to go to to break 64bits).

pavon 6y ago
I know it is a joke, but 64bit fixed-point representation with nanosecond resolution has just ~585 years of range. With 1e100 years of range needed to measure out to the heat-death of the universe, you end up with resolution of ~5e80 years, which is 60 orders of magnitude longer than the current age of the universe. It is easy to run out of bits when trying to use a single number as both an absolute date/time, and to compute relative durations between timestamps with reasonable precision. I've lost track of the number of bugs I've fixed where someone assumed a double would be big enough without doing the math.
3JPLW 6y ago
Hunh? January 1, 1970 + 9.007199254740992e15 nanoseconds gets you all the way to... tax day[1]. Microseconds gets you to the year 2255; milliseconds to heat death. 1. https://www.wolframalpha.com/input/?i=January+1%2C+1970+%2B+9.007199254740992e15+nanoseconds https://www.wolframalpha.com/input/?i=January+1%2C+1970+%2B+...
- pavon 6y ago
  Qwibble: Microseconds gets you to the year 2540 with double precision, because the implied 1-bit means you effectively have 54-bit mantissa.

fanf2 6y ago

Yes, 64 bits is not really comfortable for a long-term timestamp format. The NTP nanokernel uses a 64.64 integer represention https://papers.freebsd.org/2000/phk-nanokernel/ https://papers.freebsd.org/2000/phk-nanokernel/ because 32 bits isn't enough above the binary point because it runs out in 2038, and below the binary point you need 64 bits to accurately represent the nanosecond-scale frequency of the CPU's cycle counter to translate it to wall-clock time.