// Personal website of Chris Smith

The longest way to represent a date

Published on

The other day, someone on IRC posed this question: “What is the longest way to represent a date using any means possible that isn’t just repeated filler?”

Some people jumped for writing the date out in languages that had longer translations. My immediate reaction was instead to suggest an obnoxious string-based representation of a unix timestamp: “one second after one second after one second after … midnight on January 1st 1970”. It’s very repetitive, but it’s not filler: taking out any of the repetitions would change the value. Effectively it’s a successor function for unix timestamps, writ long. Some quick napkin maths suggests the full string representation would be around 30GiB1.

An obvious approach to make it bigger is to make it more precise. If we do the same sort of successor function for milliseconds it’d be a bit over 1000x longer2. It actually ends up being just over 35TiB3.

There’s no reason to stop there, though. You can step down to microseconds, nanoseconds, and so on… or… we can just skip right to the end. How about: “one oscillation of the caesium-133 hyperfine transition frequency after one oscillation of the caesium-133 hyperfine transition frequency after … midnight on January 1st 1970”? There are over 9 billion of those every second, and the phrasing is wordy. That comes out to almost 1ZiB4. If we pooled all the data storage on the planet together we could save a couple hundred of these timestamps.

One final step, then: why use the unix epoch when we could use the universe’s own5? We’re something around 4×10^17 seconds past the big bang, so… hold on, I need to look up some units… that’d be over 200,000 yobibytes6. There’s not actually a standard prefix for that order of magnitude, according to Wikipedia. I think it should be 200 robibytes. Does anyone have a contact at the IEC?

That is a big number. Is it impossibly big? If we wanted to track our current time, we’d need to write around 600GiB/s7 to disk. That’s a bit more than we can manage at the minute, but isn’t completely outrageous. What about storage? Apparently hard drives require around a million atoms to store a bit of data. There’s some research showing it’s possible to use as few as 12, but I don’t think it’s anything that can be used at scale anytime soon8. So just for the direct data storage, not counting all the other infrastructure you need for a disk drive to work we’d need around 10^36 atoms. If we sourced our atoms for our local paperclip maximiser we’d need around 200 trillion paperclips. For just one timestamp.

On the plus side, this timestamp format would compress wonderfully.

  1. 17 bytes of repetition * 1773528583 seconds ~= 3×10^10. ↩︎

  2. There’d be a thousand times more repetitions, and each one would have the extra five bytes from the “milli” prefix. ↩︎

  3. 22 bytes of repetition * 1773528583000 milliseconds ~= 3×10^13. ↩︎

  4. 72 bytes of repetition * 1773528583 seconds * 9192631770 oscillations per second ~= 1×10^21. ↩︎

  5. Other than it being impractical, not known to a decent accuracy, and the myriad other problems, of course. ↩︎

  6. 72 bytes of repetition * 4×10^17 seconds * 9192631770 oscillations per second ~= 3×10^29. ↩︎

  7. 72 bytes of repetition * 9192631770 oscillations per second ~= 6×10^11. ↩︎

  8. Not that we could scale conventional drives up this much, either. ↩︎

This content is also published/discussed on these external sites:

Have thoughts that transcend nodding? Send me a message!

Related posts

Christmas Tree from Advent of Code 2005

Over-the-top optimisations with Nim

For the past few years I’ve been taking part in Eric Wastl’s Advent of Code, a coding challenge that provides a 2-part problem each day from the 1st of December through to Christmas Day. The puzzles are always interesting — especially as they get progressively harder — and there’s an awesome community of folks that share their solutions in a huge variety of languages. To up t...
The Restic logo — a gopher with two umbrellas.

Simple backups with Restic and Hetzner Cloud

I have a confession: for the past few years I’ve not been backing up any of my computers. Everyone knows that you should do backups, but actually getting around to doing it is another story. Don’t get me wrong: most of my important things are “backed up” by virtue of being committed to remote git repositories, or attached to e-mails, or re-obtainable from the original sourc...
Filament weight display

Project log: Filament weight display

One problem I have when 3D printing is that it’s hard to gauge whether there’s enough filament left on a roll to complete a print. Sometimes it’s obvious when the print is small or the roll is full, but often it’s not. If I’m unsure about it, I end up obsessing over the printer instead of just leaving it to do its thing. The typical approach to this problem is to use ...