4 ms·

Time should be a signed int with enough bits to go backward from the epoch at t=0 to the big bang at t=negative whatever.

marcosdumay 6y ago
In what resolution? What do people that need higher resolution use? And the people that don't care about that amount, do they pay the performance penalty? Every physical or humane value is hard to some extent.
aw1621107 6y ago
> enough bits to go backward from the epoch at t=0 to the big bang at t=negative whatever. For reference, the universe is about 13.787 billion years old [0]. That's about 13.787 * 10^9 * 365 * 24 * 3600 = 4.348 * 10^17 seconds, which (I think?) is a 59-bit number [1]. 10ths of a second will require 62 bits, which is right about at the edge of what a 64-bit signed integer will allow. If you want milliseconds, you'll need at least 69 bits. For nanoseconds, you'll need at least 89 bits. So you'll either need an integer type that's wider than what's natively supported in most hardware (thus potentially sacrificing performance), or you'll have to sacrifice precision. [0]: https://en.wikipedia.org/wiki/Age_of_the_universe https://en.wikipedia.org/wiki/Age_of_the_universe [1]: https://www.wolframalpha.com/input/?i=13.787+*+10%5E9+*+365+*+24+*+3600+to+binary https://www.wolframalpha.com/input/?i=13.787+*+10%5E9+*+365+...
- AnimalMuppet 6y ago
  Just go for it. In the larger scheme of things, it's not that long until 128-bit CPUs. I'm mostly kidding. But if you're thinking of representing nanoseconds since the big bang, the wait for 128-bit CPUs is not very long...
  - shakna 6y ago
    GNU has extensions to support 128bit number types [0] already, for systems that can handle it. [0] https://gcc.gnu.org/onlinedocs/gcc/_005f_005fint128.html https://gcc.gnu.org/onlinedocs/gcc/_005f_005fint128.html
- syrrim 6y ago
  struct timespec already exists and stores time as two 64 bit integers. Should last a little while.
  - aw1621107 6y ago
    Ah, that's something I wasn't aware of. Yeah, that scheme could work if you didn't need a single integer to represent time.
jasonwatkinspdx 6y ago
So, the problem is a 64 bit int only gives you ~500 years around the epoch at nanosecond resolution. That's sufficient for timestamping, but not great for a general purpose time library where even ordinary civil calculations might exceed that range, particularly in intermediate arithmetic. Since larger than 64 bit ints are a disaster for portability, the reasonable solution is to go with a 64 bit signed seconds, 32 bit nano offset field. A lot of language std libs have adopted something along these lines. DJB was advocating for everything to be in a format like this, referenced to TAI (UTC without leap seconds, basically). Sadly that didn't get any traction.
- ClumsyPilot 6y ago
  I remember in my University years i was astounded to find out that none of the programming languages we were taught could represent the Jurrasic period, or the day the earth was formed, as a date. I was horrified even more when i learned that future leap seconds are undefined, and we literally can't tell what is the time on the clock lik3w a million seconds from now.
fennecfoxen 6y ago
This only really really works if you do TAI. Down with leap seconds.

marcosdumay 6y ago

In what resolution? What do people that need higher resolution use? And the people that don't care about that amount, do they pay the performance penalty? Every physical or humane value is hard to some extent.

aw1621107 6y ago

> enough bits to go backward from the epoch at t=0 to the big bang at t=negative whatever. For reference, the universe is about 13.787 billion years old [0]. That's about 13.787 * 10^9 * 365 * 24 * 3600 = 4.348 * 10^17 seconds, which (I think?) is a 59-bit number [1]. 10ths of a second will require 62 bits, which is right about at the edge of what a 64-bit signed integer will allow. If you want milliseconds, you'll need at least 69 bits. For nanoseconds, you'll need at least 89 bits. So you'll either need an integer type that's wider than what's natively supported in most hardware (thus potentially sacrificing performance), or you'll have to sacrifice precision. [0]: https://en.wikipedia.org/wiki/Age_of_the_universe https://en.wikipedia.org/wiki/Age_of_the_universe [1]: https://www.wolframalpha.com/input/?i=13.787+*+10%5E9+*+365+*+24+*+3600+to+binary https://www.wolframalpha.com/input/?i=13.787+*+10%5E9+*+365+...

AnimalMuppet 6y ago
Just go for it. In the larger scheme of things, it's not that long until 128-bit CPUs. I'm mostly kidding. But if you're thinking of representing nanoseconds since the big bang, the wait for 128-bit CPUs is not very long...
- shakna 6y ago
  GNU has extensions to support 128bit number types [0] already, for systems that can handle it. [0] https://gcc.gnu.org/onlinedocs/gcc/_005f_005fint128.html https://gcc.gnu.org/onlinedocs/gcc/_005f_005fint128.html
syrrim 6y ago
struct timespec already exists and stores time as two 64 bit integers. Should last a little while.
- aw1621107 6y ago
  Ah, that's something I wasn't aware of. Yeah, that scheme could work if you didn't need a single integer to represent time.

jasonwatkinspdx 6y ago

So, the problem is a 64 bit int only gives you ~500 years around the epoch at nanosecond resolution. That's sufficient for timestamping, but not great for a general purpose time library where even ordinary civil calculations might exceed that range, particularly in intermediate arithmetic. Since larger than 64 bit ints are a disaster for portability, the reasonable solution is to go with a 64 bit signed seconds, 32 bit nano offset field. A lot of language std libs have adopted something along these lines. DJB was advocating for everything to be in a format like this, referenced to TAI (UTC without leap seconds, basically). Sadly that didn't get any traction.

ClumsyPilot 6y ago
I remember in my University years i was astounded to find out that none of the programming languages we were taught could represent the Jurrasic period, or the day the earth was formed, as a date. I was horrified even more when i learned that future leap seconds are undefined, and we literally can't tell what is the time on the clock lik3w a million seconds from now.

fennecfoxen 6y ago

This only really really works if you do TAI. Down with leap seconds.