@simon_brooke @catgirlQueer @vashti Just to be safe you should follow RFC2550.

https://www.rfc-editor.org/rfc/rfc2550.txt

This discusses future granularity and extended time range requirements. It errs on the side of caution eliminating any risk of obsolescence. As the RFC says:

In any case, the prevailing belief is that the life of the universe (and thus the range of possible dates) is finite.
However, we might get lucky. So, Y10K dates are able to represent any possible time without any limits to their range either in the past or future.

@simon_brooke @catgirlQueer @vashti

https://en.wikipedia.org/wiki/Network_Time_Protocol

NTPv4 introduces a 128-bit date format: [...] According to Mills, "The 64-bit value for the fraction is enough to resolve the amount of time it takes a photon to pass an electron at the speed of light. The 64-bit second value is enough to provide unambiguous time representation until the universe goes dim."

@simon_brooke @catgirlQueer @vashti

Fun fact:

Until 1972-01-01Z we used rubber-time, because astrometry is not nearly as constant as most people seem to think.

But it is worse than that.

We literally have no idea how long nanoseconds took before 1958-01-01Z

If you go back before observations of solar eclipses, we even barely know how long days took.

Any epoch before 1972-01-01Z by defintion causes wrong timekeeping.

@simon_brooke @catgirlQueer @vashti Good point.

Once Upon A Time two second resolution was fine, because nobody could create two files within two seconds, because floppy disks just weren't that fast.

Then millisecond resolution was good enough, until software started writing multiple log lines in the same millisecond, and their order isn't preserved if you're using Elasticsearch for your logging database.

We seem to have learned from this and skipped microseconds, but yes, the day might come when nanoseconds aren't good enough.

@simon_brooke @kevingranade @vashti i would imagine this depends on the runtime? This only works if your language is very object-y, since bigints are handled through indirection, and you'd need to tag the difference between the pointers and integers.

And I don't think the overhead is a question of catching overflows, it's dealing with all the conditions, now you would have an if-statement at least at every reciever from the DB. (unless integers are already indirected in that lanaguage, in which case there is dynamic dispatch overhead for every arithmetic operation)

And BigInt support is software land, not hardware, which means you can't re-use registers and such, but have to cycle them in and out of memory, which I would presume to have a pretty decent overhead in compute time and memory bus (the actual bottleneck in modern computing).

Or at least that's what I'd figure, I'm not a professional or anything so I'd love to hear your thoughts.