3 ms·
That's unnecessarily complicated. A 64-bit signed Unix time fixes this for 25x longer than the remaining lifetime of the sun.
by paulddraper 3y ago
That's unnecessarily complicated.
A 64-bit signed Unix time fixes this for 25x longer than the remaining lifetime of the sun.
- Kamq 3y agoOur descendants around alpha centauri are going to have so much legacy code to upgrade.
- maxerickson 3y agoEver read A Deepness in the Sky?
- paulddraper 3y agoWow that brings back memories
- nly 3y agoUnless you want to keep time to nanosecond granularity, like in a typical modern trading system. Then you have only +/- 292 years.
- matheusmoreira 3y agoWhat if we have picosecond precision timers in the future? Femtosecond precision timers? Who knows, right?
- paulddraper 3y agoTrue, but here we're taking about Unix time, which is seconds since 1970 UTC. AFAIK, most systems with absolute nanosecond precision use two 64-bit ints.
- nly 3y agoIn my experience unix time in units finer than seconds is more common than not. The NYSE stock exchange uses nanos since Unix epoch as a single 64bit int. I've never seen someone waste a whole second 64bits
- School-Cotton 3y agoOk, then in those cases use 128 bits.
- paulddraper 3y agoUnix time is by definition "seconds since Unix epoch." It common to have other measurements, e.g. JS uses milliseconds since epoch. But technically that isn't "Unix time"
- zzo38computer 3y agoIf you want to deal with date/time properly, then you will need a separate field for nanoseconds anyways, in order to deal with leap seconds; in such a case the number of nanoseconds can exceed one billion. In such a case the nanoseconds can fit in 32-bits and you don't need 64-bits; only the seconds is 64-bits and nanoseconds is 32-bits.
- nly 3y agoWhat are you talking about. A single 64 bit int is plenty for nanoseconds since epoch