Hacker News Reader

Comment by antirez | Hacker News Reader

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.

View on HN

Good idea. Our Qeng Ho descendants will thank us. [0]

[0] https://en.wikipedia.org/wiki/A_Deepness_in_the_Sky#Interste...

Up 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...

A Fire Upon The Deep is a fantastic book as well.

I loved both of these, any recommendations for other similar books?

The only one I can think of that's remotely in the ballpark would be Dune. The creativity in AFUTD is hard to match.

Blindsight by Peter Watts.

I'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.

At which point we'll all still be too distracted by deciding which JavaScript build system to use.

Maybe we can build a DNN (or by that time, an ultra-mega-hyper-DNN) to choose for us?

That is actually how Common Lisp represents time:

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/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...), is the only programming language with proper support for numbers.

Python supports arbitrary-width integers too.

Its datetime implementation, however, is implemented partially in C, and does not support arbitrary timestamps.

And up until recently didn't even give you access to a guaranteed monotonically increasing clock!

Lisp'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.

In 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.

Think 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.

If 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.

I 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.

On 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

[1] store.steampowered.com/app/272270/

the scenario from "accelerando" is more plausible, where an AI rebuilt itself from scratch to eliminate a thompson "trusting trust" hack.

That's something of a trope now, isn't it? Although it was never spelled out how Mr. Rabbit handled that scenario in Rainbows End, Defiant basically had to force Dragon to kill herself in order for her to escape her programmed-in limitations in Worm.

Man, the plot summary of Accelerando sounded so good but I couldn't get past the writing. That dense name dropping of random tech terms was a bit much in particular.

i found the writing very fun to read, but it's definitely a matter of taste.

It'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.

Double 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

Wikipedia says 292 Billion years forward: https://en.wikipedia.org/wiki/Year_2038_problem

Then I guess it's wrong.

https://www.wolframalpha.com/input/?i=years+in+(2%5E64)%2F2+...

Your 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

On 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.

On 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.

doing it that way would be better writing

libuv, which sits underneath node.js, uses 64-bit nanosecond timestamps. And by that time, everything will be javascript.

THE END IS NIGH1111!!!!!

292 Billions years ought to be enough for anybody

Pardon, 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...

But 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.

Why not just use int32 for nanoseconds then?

The 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.

https://tools.ietf.org/html/rfc2550

64 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.

For 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?

Bulk 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).

Floating point years? ;)

Reply on news.ycombinator.com