- An hour ago (15:47)
- Last week (MON 12 SEP 9:20)
- Two years ago (WED 14 APR 2021 11:47)
Date format to taste, of course. - An hour ago (15:47)
- Last week (MON 12 SEP 9:20)
- Two years ago (WED 14 APR 2021 11:47)
Date format to taste, of course.- relative rendered on page
- actual time stamp / date format in a tooltip over relative
If people want more detail they can hover mouse over the relative date.
Also, I find myself needing to copy and paste information like this every now and then, which a tooltip is horrible for.
Also:
- 2 years ago
- 2021-12-31
How is that a space issue?
need more room for the ads obviously.
>How is that a space issue?
it's all relative, but in your example you added a new line. Think of this HN comment section with 200 comments on a page and how much scrolling you need to add due to that decision.
Of course, the comment's design up the chain doesn't have this issue. But for horizontal space mobile is still going start to feel cramped when you add a time stamp to the existing:
[name] | 3 hours ago | root | parent | next [–]
because resolution means a lot less for mobile due to the smaller screen. Despite the much higher resolution there's less room to do things there due to the orientation and the size needed for readable text.
This can all be addressed with the best of both worlds using responsive design, but it requires smart design that is aligned with a goal of deliveing dense information. As you hinted at, that simply isn't the current goal for modern design. Less "newspaper" where the goal is to fit in information, and more "ad flyer" where the goal is to focus attention on the biggest eye catches and leave little else (except ads) to distract .
2h ago is now wrong unless it refreshes
15:35 is still correct.
Rendering relative dates instead of actual is not a good user experience in my opinion.
Personally, if I'm looking at a date at all that's because I want to compare it to another date.
Why it's important for work-related stuff doesn't need explaining, I guess. But this is relevant even for personal matters -- e.g., was this photo taken before a friend's wedding or after, etc.
Given how imprecise relative dates are they are not of much help for that.
And in the case I'm not looking to compare dates, seeing relative dates doesn't really add any value for me either.
Also, it's quite obvious something happened 1, 2, 3 years ago from seeing the actual date.
- a tooltip
- that has to be made copyable
- by a context menu
This is what I did for a job code challenge - relative casual time in the main description, and then complete time details under the item: https://imgur.com/qG0US5o
OTOH I'm still looking for a job, so YMMV ;)
And I'm not sure it should be a link. Using the displayed time for a permanent link to a post - while ubiquitous - is a weird UI hack.
Edit — I’m not a frontend dev. I shall defer to their expertise in said matters.
With the prevalence of emoji and higher resolution displays, I wonder if tooltip hinting with an obnoxious question-mark or magnifying-glass image would be sufficient to hint to older/less-savvy users.
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.