Why? What's wrong with just the date?
When I’m looking at when a merge request was merged in to master in gitlab, often the level of granularity I am interested in is ‘roughly how long ago’, or ‘what day in the last week was that?’ - the thing I am trying to figure out is just ‘did that go live last Tuesday or last Wednesday?’
I can recover that information from a date with a little mental arithmetic or a cross lookup to a calendar but it would be nice if the computer told me that.
On the other hand, sometimes when I am looking for when a git merge request was merged in I am looking for ‘was it a few minutes before or a few minutes after this error started happening in production?’ And the precise timestamp is of intense interest. At that point seeing a bunch of merge requests tagged as ‘last Tuesday’ is incredibly unhelpful to me. But so would just an unadorned date be.
In general I would lean towards providing the information in a raw form but also contextualized.
But ‘just a date’ is often the worst of both worlds. Even worse if I don’t know which time zone the date is being reported relative to (people often display UTC dates without clarifying that, or even considering that dates need time zone adjusting too).
My dream contextualized timestamp would be something like
2023/10/09 13:47:20 (Monday, 5 days ago)Of course, this brings up that text date strings are often vague/could have multiple interpretations.
I think -- but don't take my word for it -- it was Jeff Atwood who started advocating for it.
So we might be talking not about removing a feature, but correcting a mistake here :)
Personally, if I care about a timestamp at all it's because I want to compare it to another date (maybe a past date, maybe a present or future one): a deadline, an event, a birthday. Relative dates actually make such comparisons harder.
On the other hand, seeing an actual date like 2022/10/03 it's dead simple to tell that was a year ago, it's equally easy to tell whether something happened this year, or last month, or two days ago, etc.
Another nitpick is that relative dates solve the date format issue. No need to fuss over YYYY/MM/DD or DD/MM/YYYY or any other permutation, but we all can agree on when "7 months ago" was.
Less trivial is taking into account time zones. if you're traveling and have some jet lag, "10:30" may not actually mean 10:30 to your biological clock. but "in one hour" is universal (even if your body is confused).
But if I am travelling it is even more error prone for my computer to compute the correct difference.
Relative time is only useful within the next or past few hours. For pretty much everything else, the absolute time is more informative and clear.