6 ms·
Using a 64 bit timestamp will only move the problem 292 million years forward, so probably the best solution is to use a variable length field.
by antirez 10y ago
Using a 64 bit timestamp will only move the problem 292 million years forward, so probably the best solution is to use a variable length field.
- jpm_sd 10y agoGood idea. Our Qeng Ho descendants will thank us. [0] [0] https://en.wikipedia.org/wiki/A_Deepness_in_the_Sky#Interstellar_culture https://en.wikipedia.org/wiki/A_Deepness_in_the_Sky#Interste...
- hunterjrj 10y agoUp vote for the Deepness reference! What a great novel, and I suspect the concept of a "programmer archaeologist" would be of interest to many here...
- Nition 10y agoA Fire Upon The Deep is a fantastic book as well.
- placeybordeaux 10y agoI loved both of these, any recommendations for other similar books?
- Nition 10y agoThe only one I can think of that's remotely in the ballpark would be Dune. The creativity in AFUTD is hard to match.
- hunterjrj 10y agoBlindsight by Peter Watts.
- jraines 10y agoI'm a big fan of both and I recently loved Diaspora by Greg Egan. It's a bit more heavy on math/physics references but it's still amazing writing and an epic piece of world (and universe) building.
- swalsh 10y agoThink about how much entropy will build up in systems over 292 million years. Systems thousands of years old will be underneath newer systems hundreds of years old. The AI's will be scrambling to fix the problem.
- ejcx 10y agoIf humans are still alive 292million years in the future, seems like that's our best time to take control back from our sentient AI overlords.
- Retric 10y agoI think this would make a great science fiction setting. Where some clock error destroys most/all the magic tech out there and humanity is doing hunting and gathering on space stations etc.
- Razengan 10y agoOn a tangent, take a look at Numenera [0][1]. It's set a billion (!) years in the future, but different from other ultra-science fiction or post-apocalyptic settings in that it primarily explores what Earth would be like after accumulating multiple layers of incomprehensibly advanced supertechnology, the true purpose of which cannot ever be understood by the current inhabitants, and at best they can only reverse-engineer a fraction of the original functionality. [0] http://www.numenera.com http://www.numenera.com [1] store.steampowered.com/app/272270/
- deleted 10y ago[deleted]
- zem 10y agothe scenario from "accelerando" is more plausible, where an AI rebuilt itself from scratch to eliminate a thompson "trusting trust" hack.
- jessaustin 10y ago
- TillE 10y agoIt's kind of impressive the scale of data you can represent when you merely double those very limited 32 bits. Obviously not enough to count every nanosecond in the history of the universe (128 bits would be more than enough for that), but still.
- jodrellblank 10y agoDouble again to 256 bits, and there isn't enough energy in the mass of the solar system to power the most efficient state change device conceivable through 2^256 state changes. https://security.stackexchange.com/a/6149/1427 https://security.stackexchange.com/a/6149/1427
- keithlfrost 10y agoOn the other hand, using a 64 bit integer to count seconds moves the problem 292 billion years forward, and we can probably let the Omega Point handle it from there.
- twic 10y agoOn the other other hand, getting greedy and using a 64 bit integer to count nanoseconds only moves the problem 448 years forwards. That's long enough to seem like it's perfectly safe, but short enough that it might just not be.
- asperous 10y ago292 Billions years ought to be enough for anybody
- mikesickler 10y agoWikipedia says 292 Billion years forward: https://en.wikipedia.org/wiki/Year_2038_problem https://en.wikipedia.org/wiki/Year_2038_problem
- devcpp 10y agoThen I guess it's wrong. https://www.wolframalpha.com/input/?i=years+in+(2%5E64)%2F2+milliseconds https://www.wolframalpha.com/input/?i=years+in+(2%5E64)%2F2+...
- C4K3 10y agoYour example counts milliseconds. It is 292 billion, from units: You have: (2^64 / 2) seconds You want: years (2^64 / 2) seconds = 292277265670.798 years
- jentulman 10y agoAt which point we'll all still be too distracted by deciding which JavaScript build system to use.
- jabl 10y agoMaybe we can build a DNN (or by that time, an ultra-mega-hyper-DNN) to choose for us?
- antirez 10y agoPardon, it's billion indeed if you count seconds. I wrote millions for mistake, but thinking about it once you have 64 bits, milliseconds are nice to have...
- ekimekim 10y agoBut once you have milliseconds, microseconds are nice to have... The linux kernel (and many other applications) solve this with a tuple of 64-bit ints (seconds, nanoseconds) where 0 <= nanoseconds <= 999999999. Compare this to simply 64 bits of nanoseconds, which would run out in roughly 2554 CE. Other systems still (perhaps most commonly) are using double floats for seconds. Under that scheme, nanoseconds were only representable until Feb 17th 1970. The last representable microsecond will be some time in 2106, and the last representable second won't be for another 150 million years or so. Personally, I'm happy with the precision afforded by floats. Timing uncertainly (outside niche applications) is generally much larger than a single nanosecond, and even microseconds are a bit suspect.
- tdhoot 10y agoWhy not just use int32 for nanoseconds then?
- Dylan16807 10y agoThe nanoseconds field in timespec is actually a long, for some reason. I have no idea why it's not fixed-size. Let's not even get into timeval which uses the same size field for microseconds.
- jwilk 10y agohttps://tools.ietf.org/html/rfc2550 https://tools.ietf.org/html/rfc2550
- sedachv 10y agoThat is actually how Common Lisp represents time: https://www.cs.cmu.edu/Groups/AI/html/hyperspec/HyperSpec/Body/sec_25-1-4-2.html https://www.cs.cmu.edu/Groups/AI/html/hyperspec/HyperSpec/Bo... When you look up "integer": https://www.cs.cmu.edu/Groups/AI/html/hyperspec/HyperSpec/Body/syscla_integer.html#integer https://www.cs.cmu.edu/Groups/AI/html/hyperspec/HyperSpec/Bo... "An integer is a mathematical integer. There is no limit on the magnitude of an integer." What happens when an integer overflows from a fixnum (single-word representation) is that it gets upgraded to a bignum behind the scenes. IMO Common Lisp is the only programming languages that handles time correctly out of the box, and aside from Scheme (http://www.schemers.org/Documents/Standards/R5RS/HTML/r5rs-Z-H-9.html#%_sec_6.2.1 http://www.schemers.org/Documents/Standards/R5RS/HTML/r5rs-Z...), is the only programming language with proper support for numbers.
- MHordecki 10y agoPython supports arbitrary-width integers too. Its datetime implementation, however, is implemented partially in C, and does not support arbitrary timestamps.
- callalex 10y agoAnd up until recently didn't even give you access to a guaranteed monotonically increasing clock!
- kbp 10y agoLisp's support for numbers goes beyond automatic bignum promotion, for example (/ 1 3) gives the rational 1/3 instead of an approximation, and (sqrt -1) gives #C(0.0 1.0), that is, 0 + 1i.
- lispm 10y agoIn systems one still needs to interface Common Lisp with the real world in correct ways. Reading & printing dates in various formats wasn't always correct in some applications.
- mcbits 10y ago64 bits only cover about 7 months at picosecond resolution, so it's possible that 64 bit timestamps will be too small sometime this century, depending on how tightly synchronized the world becomes. An extensible timestamp might not be a bad idea and could still be kept under 64 bits for currently practical purposes.
- Sean1708 10y agoFor picosecond resolution to be useful wouldn't clock rates need to be on the order of THz? Otherwise what advantages would ps resolution give you over ns?
- mcbits 10y agoBulk data processing clock speeds could still be lower, but some devices may need THz timing, for example to align and integrate data from a swarm of sensors in motion relative to each other. Imagine trillions of 1-pixel cameras that know exactly when, where, and in which direction each pixel was captured (but not necessarily capturing literal image data).
- shthed 10y agoFloating point years? ;)