4 ms·

Exhibit B: yes, the command that repeatedly prints `y` to stdout. Exhibit C: all handling of time, with time_t, struct timespec, timeval etc. We should just hav

Exhibit B: yes, the command that repeatedly prints `y` to stdout. Exhibit C: all handling of time, with time_t, struct timespec, timeval etc. We should just have a 64 bit uint representing nanoseconds from epoch, which would give us 585 years and get rid of much nonsense. [1] https://github.com/coreutils/coreutils/blob/master/src/yes.c https://github.com/coreutils/coreutils/blob/master/src/yes.c

throwhypothetic 6y ago
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.
wool_gather 6y ago
...? `yes` is not part of the C standard library.
- bigbubba 6y ago
  I think they meant to draw attention to the implementation of `yes` to showcase crustiness the C stdlib imposes on even a trivial program. But of course GNU is kind of notorious in this regard. Compare their `yes` to OpenBSD's. It's night and day. https://github.com/openbsd/src/blob/master/usr.bin/yes/yes.c https://github.com/openbsd/src/blob/master/usr.bin/yes/yes.c
  - identity0 6y ago
    It's not that GNU is incompetent or overly bureaucratic or anything. It's that they really didn't want to infringe on Unix, and they presumed that Unix's yes would have been implemented in the most obvious, dead-simple way. And, as a plus, GNU yes can stream y's at like 10 GB/s, if you need that.
Gibbon1 6y ago
In my firmware I keep time as a 64 bit signed number that counts 32.768 khz ticks since the unit powered up. I think it'll roll over in 8 million years or something like that. If you want to know what's broken? Most real time clock modules. They almost all want to store time as HH:MM:SS MM:DD:YY and sometimes 1/256 of a second but sometimes not.

throwhypothetic 6y ago

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.

wool_gather 6y ago

...? `yes` is not part of the C standard library.

bigbubba 6y ago
I think they meant to draw attention to the implementation of `yes` to showcase crustiness the C stdlib imposes on even a trivial program. But of course GNU is kind of notorious in this regard. Compare their `yes` to OpenBSD's. It's night and day. https://github.com/openbsd/src/blob/master/usr.bin/yes/yes.c https://github.com/openbsd/src/blob/master/usr.bin/yes/yes.c
- identity0 6y ago
  It's not that GNU is incompetent or overly bureaucratic or anything. It's that they really didn't want to infringe on Unix, and they presumed that Unix's yes would have been implemented in the most obvious, dead-simple way. And, as a plus, GNU yes can stream y's at like 10 GB/s, if you need that.

Gibbon1 6y ago

In my firmware I keep time as a 64 bit signed number that counts 32.768 khz ticks since the unit powered up. I think it'll roll over in 8 million years or something like that. If you want to know what's broken? Most real time clock modules. They almost all want to store time as HH:MM:SS MM:DD:YY and sometimes 1/256 of a second but sometimes not.