> Using clever encodings to save space or sort time in the context of an exchange server for this amount of data probably hasn’t been an appropriate choice in at least a couple decades.
What makes this weird is that, as hn_throwaway_99 notes, this isn't even a clever encoding. It's a stupid encoding that fails at the tasks of saving space or time. Both of those are accomplished better by the ordinary timestamp value that everything uses. Converting the timestamp to a string and then interpreting that string as an integer brings you:
- A less dense encoding: any value of a timestamp correctly represents a time, but not every value of an integer represents a date format string. You just introduced invalid dates into an encoding that had no reason to contain them.
- Equal sorting times: sorting integers is more or less the same no matter what the integers are.
- Vastly increased processing times: in the naive approach, you're handed a timestamp, which is an integer, and you use it directly. In this "optimized" approach, you're handed a timestamp, you convert it to a string, and then you convert the string back to another integer. This new integer is encoded so that you can't even mask out the bits you want, because the information you care about is stored in powers of 10 while the integer is represented in powers of 2. What did you gain?
This is not a date string. It's a version number. The version number happens to have a date embedded inside it. That's not for the computers, but for the humans looking at it to be able to get some useful information at a glance. The app was treating it simply as a version number and caring about "which is higher?" and nothing else.
What makes this weird is that, as hn_throwaway_99 notes, this isn't even a clever encoding. It's a stupid encoding that fails at the tasks of saving space or time. Both of those are accomplished better by the ordinary timestamp value that everything uses. Converting the timestamp to a string and then interpreting that string as an integer brings you:
- A less dense encoding: any value of a timestamp correctly represents a time, but not every value of an integer represents a date format string. You just introduced invalid dates into an encoding that had no reason to contain them.
- Equal sorting times: sorting integers is more or less the same no matter what the integers are.
- Vastly increased processing times: in the naive approach, you're handed a timestamp, which is an integer, and you use it directly. In this "optimized" approach, you're handed a timestamp, you convert it to a string, and then you convert the string back to another integer. This new integer is encoded so that you can't even mask out the bits you want, because the information you care about is stored in powers of 10 while the integer is represented in powers of 2. What did you gain?