A decimal digit encodes approximately 3.3 bits. The current Unix timestamp (barely) fits into 32 bits, so it should take approximately 10 decimal digits to repr

A decimal digit encodes approximately 3.3 bits. The current Unix timestamp (barely) fits into 32 bits, so it should take approximately 10 decimal digits to represent. The number of seconds since the beginning 0 CE fits into 36 bits, so requires 12 decimal digits at least. The ISO timestamp (YYYY-mm-dd HH:MM:SS) requires 4 + 4 + 6 = 14 decimal digits. If we wanted to compress the representation while remaining within ASCII and allowing for textual sorting and easy glancing, our best bet is something like base64: Latin upper case + lower case + digits give us 66 characters, a soupçon more than 6 bits per character. We'd need only 6 characters to represent a 36-bit timestamp with 1 second precision, and just 5, for a minute precision. Yay! Better yet, since timekeeping is base 60 since Sumerian times, we could directly represent minutes and seconds with one digit each, using base60 (with a room to spare for the leap second). Relinquishing 1.5 more bits, we could use only 24 distinct values for hours, allowing for a clear separation of "date" and "time"; time would take 3 characters, like D7a. If we agree to spend 2 characters (12 bit) for month + day, then the month and the day directly map to one character each. Now allocate 2 characters for the year, and we're set until year 4095, when we could reconsider. So, we have a timestamp of 2 + 2 + 3 = 7 characters, only one longer than the theoretical minimum, and with quite a room to spare. The result directly maps to the traditional calendar dates, with year, month, day, hour, minute, second being separate digits, and which is readable, sortable, pronounceable, and trimmable. (Now we only need to write it in cuneiform again.)