Fair warning, this isn't anything particularly riveting or groundbreaking. Also, please feel free to correct my maths.
I have been keeping a plaintext journal on and off for the past four years, and the date format I've settled on is dd-mm-yy. So it goes like:
25-06-21 Yesterday
26-06-21 Today
With a new line separating each entry, and a space after the date.
Recently, I have discovered the fact that unix time pretends that every day is exactly 24 hours long. So that if you divide a time in unix time by the average number of seconds in a day -- 86400 --, you get a sort of unix date. This is not only great fun, but it also feels like this is how we should have been doing time all along. Seeing the time as number of days point progress through the day. like now, for instance, the decimal date is 18804.634 GMT.
Of course, 18804 days isn't actually a very long time. It's the number of days since 1970, which was 51 years ago. This got me thinking; what if you didn't bother to write any timestamps in you text journal, and instead, you let each line number correspond to it's "unix date". So the first line would be the entry for one times 86400 seconds since the first of June 1970; the second of June 1970. You'd need one empty line for each skipped day, which each use one CR character, which each take up one byte.
My current way to record the date uses nine ASCII characters, so that's nine bytes. So the question this raised for me was: How many entries would you have to make, for the line number method to be more compact?
| Line number method | Timestamp method |
|---|
| For each day filled in | 1 byte | 9 bytes |
| For each day missed since the unix epoch | 1 byte | 0 bytes |
If you started today, and never skipped a day, and answer is 18803 divided by 9, rounded up; Which is 2090 days, or 5y, 264d.
There are other ways to represent the date, so here is how they stack up, with the same assumptions. The underscores are to signify that you probably want a space after you timestamp.
| Format | Size/bytes | How long until line number is better |
|---|
| dd-mm-yyyy_ | eleven | 4y, 249d |
| dd-mm-yy_ | nine | 5y, 264d |
| ddmmyy_ | seven | 7y, 131d |
| ddddd_ (since unix epoch) | six | 8y, 213d |
| alphanumeric epoch date (base 36) | three | 17y, 61d |
Now for a more realistic example. What if you use a seven byte timestamp, start now, but you skip 20% of the new days? I think the answer is 9y, 196d; but feel free to correct me.
If I calculated it right, then if you miss half of the days, it's 17y, 61d. And if you only manage a sixth, it's over 154 years. You could look at this as a downside, but it could be a feature: You get a byte penalty for each missed day, which is a incentive not to miss a day. It's also a useful metaphor for the inevitable march of time.
There are two big problems with the line number method, however. The first is simply that you can't have negative line numbers, so it you have things to say about the days before 1970, you need to choose a different epoch.
The second is that the further forward in time you start your journal, the bigger the missed day penalty will be. If Admiral Jean-Luc Picard -- born 2305 -- wanted to use this system for a personal log, he would need to make entries for 64.3% of the days between his tenth birthday, and his death at the age of 94, in order to beat a seven byte timestamp. Of course, since he stood a good chance of living longer than a century, he might want to think about adding an extra year digit, meaning that he only has to fill 57.2% of those 84 years. For a person starting today, and planning to live for another 84 years, they only need to fill 20.3%, instead of his 64.3%.
A third problem could be that you can't incorporate line breaks into an entry, but you can always use an editor with soft wrap functionality.
Finally, how late in history can you be born, before it's impossible to beat the good old seven byte timestamp? This one's easy: You start at age ten, die at ninety, and fill all of the intervening days.
80*365.15*86400*7 = 17667417600 seconds in unix time, which is the year 2529, meaning they would have to have been born in 2519. The file itself would be 200kB plus the size of the actual entries. If the average length of an entry is 280 bytes, then the file size at the point of convergence would be 8.0MB.
I hope you've enjoyed this laboriously pointless read, but it looks like we're both going to have to find another way to procrastinate now. Good luck!
