Anything longer ago than yesterday should just say the actual date
grumpy.website
grumpy.website
So if I see two videos that were both uploaded "a year ago", it's impossible to know which is more recent without actually opening the videos, going to the description, and looking at the date.
A video uploaded two years ago on 10/14/2021 would still tell you it was one year old if it were uploaded later in the day.
Then it doesn’t matter if you write it
November 12 2012
2012 November 12
12 November 2012
2012 12 November
Etc.
How would 2012 ноябрь 12 feel to you?
2021-11-21 15:10:35
See how much easier that is?
irb> puts “2021-11-21\r\t15:10:35”
2021-11-21
15:10:35RFC 3339 notes:
NOTE: ISO 8601 defines date and time separated by "T".
Applications using this syntax may choose, for the sake of
readability, to specify a full-date and full-time separated by
(say) a space character.
Note also that ISO 8601 doesn't require the "T" to be uppercase. A lowercase "t" might be slightly more readable: 2021-11-21t15:10:35
Not that avoiding such names solves the problem, it just makes the RCE vulnerability more latent.
But I don't mean to pick a Star Wars / Star Trek fight: I'm bistellar, I love both of them!
I had to fix so many of these in various databases and frontends, lol
A website/app shouldn't have to find your timezone. It should use whatever one you've set. If you've set your timezone to one you didn't want, I'm not sure what you'd expect other software is meant to do about that. Fix your config.
Even if the user set it in one time zone, if we store it without a proper offset (and preferably a locale), we cannot properly account for the user traveling to another place, daylight savings time, government time adjustments, leap time, etc. These complexities compound off each other and make proper scheduling and debugging time issues really, REALLY hard later on.
In the twenty years or so that I've been doing web dev, datetime is probably the single biggest gotcha I've seen developers (including myself) stumble into. Part of this is because the standard JS datetime handling is atrocious compared to any other language I've worked in. It doesn't really natively handle time zones well, and well carelessly cast them back and forth if you're not careful.
Moment and Luxon can help with this, lighter libs like date-fns can too with the right extensions, but out of the box JS is going to fuck it up. I promise. Another choice is to just use milliseconds to store everything, and convert that to the user's timezone only at the time of display. Every timestamp is stored as an epoch, and every user has their time zone (not just offset, because of daylight savings) recorded with their profile. Doing those two simple things can avoid most of the landmines.
And javascript natively converts epoch time to whatever timezone the client has set. If your user-agent (aka browser) is working on New York time, but you're in Tokyo, well, I'm not sure who else you have to blame but yourself if it shows you New York time when you didn't want that.
I think I'd be ok with this. I love the KDE fuzzy clock that says it's "about lunchtime", much more human than the examples people are decrying here.
In the end though we just used checksums, but over the wire the larger files take too long. This comment has given me an idea!
So for example check modified, inode number against the previous version. If they are all a match consider skipping the checksum. This way you can skip almost all checksums on an incremental transfer. You can have false-negatives but this can often be mitigated by occasionally doing a full rescan or similar.
To be honest, I didn't even try this because the destination machine is Windows, I didnt think inode number had an equivalent in windows, but after googling, there might be a way.
Another great suggestion.
As for the full checksum, I went with a chunk size of the first and the last of the file, (the changes are very small, property based) but I don't think its as reliable.
1 - I rarely eat a meal in the middle of my day. In fact I usually only eat once, so is that one meal lunch? or breakfast? or dinner? or what ??
2 - My day not only isn't the same as yours, it isn't even the same from day to day, so even if I agreed to call my one meal lunch instead of dinner, it does not come at the same time as yours does, and does not even come at the same time from day to day, and does not even come at the same time relative to when I am awake let alone the absoluet time.
It's inconsiderate to think this is reasonable for everyone else because it's reasonable for you. It's like how kids and the untravelled and otherwise ignorant presume everyone else's life is exactly the same as theirs.
I could translate of course, because of course I know what it means for probably the majority of everyone else, but why should I have to do that? This whole topic is about convenience and meaning, and this would be inconvenient and of only arbitrary meaning to me. It would be like calling it "triangle time" sure, I could just know that that means around noon. Why should my interface require me to translate from markers that are meaningful to someone else's life but not to mine?
A worse example just to show what's so wrong would be like calling sunday "church day". Or sunday afternoon "right after church". That would be not only inconsiderate but downright offensive. For a lot of people that would be perfectly fine and some of them would even fail to see why that should be a problem for anyone.
And the offense isn't just mentioning a religion, it's the assumption, the turning anyone else into the exception, when they are not an exception, they are equal.
FTFY
When such relative dates are in a list it's generally tolerable. The failure to update is far more irritating, and limiting to "yesterday" does not fix that.
I don't want to do date math in my head! Just give me the precise timestamp!
Don't throw away information with nonsense like "1 year ago" when as the parent post says, that could mean anything in a huge range of days.
Just show the actual timestamp!
I see proper timestamps in Finder in Date Modified column.
The current generation of UI / UX people come usually from non tech backgrounds and are people very keen on... Making things pretty. They seem to know very little, however, about usability and other principles that we, developers, used to care about.
For most people, exact time doesn’t even really matter — it’s about estimating a broad chronological context for the most part. I’d just wish the UI would have a universal and easily accessible way to disclose the exact time when I actually need it.
But that is throwing out the baby with the bath water. The existence of multiple locally used data formats is no reason replace information with this oversimplified nonsense. Browser can and used to provide the locale with every request. That is enough information to format a data such that it is readable to the user.
Citing RFC 3339 is usually a better idea, since in addition to be readable for free, it is limited to the date formats you are thinking about. My 2 cents on your preferred citation, keep preaching though!
https://datatracker.ietf.org/doc/html/rfc3339
With apologies for the delayed response, I got here from the weekly hackernewsletter.
For better or worse (worse, IMHO), this is how YouTube search works. It takes at least two HTTP requests to get the precise dates. One to retreieve the SERP. Another to retrieve the JSON for each videoID. The JSON contains the upload date, etc.
IMO this sort of inefficient design pattern is faciltated by web developers who rely on Javascript, which is seemingly all of them. Webpages become shells for advertising and Javascript is used to fetch non-advertising, i.e., data. Google wants users to make clicks and track them, i.e., collect behavioural data. Thus it makes sense that a user would be forced to "open" a video to see its actual upload date.
The suite of tiny custom utilties I wrote in C can search YT and retrieve all YT videos, this can be upwards of 900 results. The output is CSV, SQL or simple HTML, including upload date and other data I find useful. This is done using only two TCP connections. No browser is needed. The simple HTML is just a page that looks like CSV, with a hyperlink to the video file. It's "YT redesigned" to look like I want it to look. I do the web development before opening the page in a browser.
The custom "downloader" I wrote is smaller, simpler and faster than yt-dlp. No Python required. But most times I don't download. I just use the simple HTML that looks like CSV. IMHO, this is much better than Google's privacy-invasive page laden with Javascript. I can see the precise dates and other useful data. I can sort by vaious columns. And I can exclude garbage videos that Google ("the algorithm") inserts into results, videos that have nothing to do with the search query string I submitted.
You don't need malice to explain that --- just A/B testing. Making information, that a user wants or needs, less accessible increases engagement, since the user is clearly clicking more.
No, they’re just stupid, or at best, ignorant to a degree that makes them incompetent.
What? Really? Checking ... yep, indeed, Youtube does have such a tooltip. How come I didn't know that? Thanks, that's very useful.
But Hackernews for stuff older than a year (maybe slihtly younger) does indeed just show the exact date for a post.
Beautifully put.
The people who do this for anything developer-related are criminally incompetent. What amazes me is that not only are they still employed, this idiocy is everywhere. From npm to GitHub to CircleCI to...
iOS mail app really irritates me with this: whenever I open it, it tells me "Updated just now". Then I pull to refresh, and suddenly there are unread emails I received 2 hours ago. Just tell me the damn time when you did the update.
https://developer.mozilla.org/en-US/docs/Web/HTML/Element/ti...
I have no idea what a browser supporting it even means. Browsers aren't supposed to do anything with it.
I wrote some JS that watches the page for these and updates them to be more user friendly and use the user's locale. But it would be nice if this was the browser's problem to solve (and can consider things like non-locale preferences such as always showing the time across websites and how far relative times should stretch)
The Semantic Web failed for the same reason: Humans click on ads but computers don't. Hence we're left with a web that is not only designed purely for human consumption, but also to appeal to the ADD part of our simian brains that says "Oooooh. Shiny!".
Do you have any source to dig deeper on this aspect? I never heard about this correlation. Then again, I'm no semantic web expert.
A criticism of social media advertising is that it’s too easy for small business to get stuck thinking that it’s work when in reality it’s just a very boring hobby. Many digital ad campaigns don’t show a return on investment so maybe that criticism applies to digital ads too…
we have such a divided world these days (the old mom and pop ads on a phone tower in town won't reach the entire country) and traditional ads are and always were untenable for a small business. They turn to digital ads because they are plum out of other ways to reach their audience properly.
When did you have such a web?
The web used to be completely server side, so you could only receive formatted HTML/CSS/JS and you would need to scrape this page to get information.
Today you have (or can have) APIs and some sites are cleanly server/client. It is much, much, much better than it was if you want to consume data. At least there is a framework for that (not always available), as opposed to before when there was none.
When I was using The Proxomitron to rewrite incoming HTML on the fly. :p
I’d say we’re actually further away from that than we’ve ever been. I’m old enough to remember <table> based designs, “best viewed at 800x600” etc etc. These days we have responsive design, adaptive color palettes for dark mode and accessibility, flags for users the prefer more contrast, reduced motion, etc etc etc.
User preference time display is interesting but I don’t think it’s realistic. My preferences can be universally applied without context.
Everything you described is nice, but in the end it’s still up to the developer to support it and especially to choose its behavior. I can technically use “when reduced motion, html {animation: shake 1s infinity}”
My idea of “user agent” is Safari’s Reader Mode.
Looking at gitlab's history for instance, it's way more helpful to know if it was merged on friday than "last week" or "2 days ago".
Same for chat history etc. happening at the limit of a month, knowing exactly if the discussion happened before or after the beginning of the month can matter a lot.
For everything else I personally could care less if it was 4 weeks ago or 2 months ago, so getting the exact date also doesn't deprive me of info.
I actually have a hard time imagining a scenario where a fuzzy date is more helpful than the exact one.
There's loads of scripts on there for Jira but I didn't see any for the dates: https://greasyfork.org/en/scripts?q=jira
You can use absolute times (ex: October 14, 2023 11:51AM) instead of relative times in GitLab by changing your preferences: https://docs.gitlab.com/ee/user/profile/preferences.html#sho...
Not only on GitLab, but everywhere. In any application. On any website. It's a pain in the ass on Linux.
C.UTF-8, but you are correct. Windows solved this years ago.
I must be misunderstanding you.
I can't get ISO-8601 dates to work properly in Excel unless I set my Windows to Australia locale, or make my own parser or use a third-party library.
Sure, I can format a field^Wcell with a custom format string, but Excel still won't believe me when I type/paste/import ISO-8601 dates. Unless I set 'Australia' systemwide.
And no, simply adding English (Australia) as one of the additional system languages, or keyboard layouts (and switching to that layout), or number+date+currency formats doesn't work.
But you could also customize the region settings in "Additional settings...".
Setting locale to `en_SOMEEUROPEANCOUNTRY` will make some programs use ISO 8601 dates everywhere, but other programs use all sorts of random formats. Switching between countries changes what different subsets of programs do.
Instead of providing a useful meaningful date, you:
- obscure information
- spent additional devtime creating a time conversion
- spent additional time implementing an otherwise useless setting for this
Why?!
It can be, in niche scenarios. I have an application that pulls information in from another database, reformats it, and displays it for the user. The update is expensive and time-consuming, so it has to be triggered manually by the user when it is needed. In this case, the exact time of the last update isn’t particularly useful; the only thing that matters is how old the data is, which is to say how likely it is to be out of sync with the source of truth. In some cases, information needs to be as up-to-the-minute as possible, so if the info is just a few hours old it needs to be refreshed. Other times, information that is 4 or 5 days out of date or longer is totally fine, so there is no need to trigger an update that could take as long as 10 minutes.
For this particular purpose, fuzzing the date is actually more useful that providing the time of the last update, since order-of-magnitude precision is good enough, and it saves the user from having to compare the update time to the current time and do a calculation. Admittedly though, this is a rare case, and the vast majority of the time a relative fuzzy date is less helpful.
I use it for communicating short-term times in the future when the recipients are across multiple time zones: "___ will finish running around 4-5 hours after this comment", "___ is fixed and will start its next run about 15 hours after this comment", etc
I think that's the proximity and actionability that makes the difference.
Check this screenshot
https://ubunlog.com/wp-content/uploads/2018/06/git-gui-gitg....
There are a number of commits marked as 3 days ago. It's only a little bit better than no information at all: or doesn't tell me if they happened in the morning or in the afternoon, or all within an hour or spread on all the day. That's important when I didn't logged how many hours I worked for a customer and I have to assess it one week later. I have to click every single commit and check the timestamp on the other side of the screen.
And screenshots are, IMHO, one important reason it should always be the full date.
- An hour ago (15:47)
- Last week (MON 12 SEP 9:20)
- Two years ago (WED 14 APR 2021 11:47)
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.
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.
- 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.
Edit — I’m not a frontend dev. I shall defer to their expertise in said matters.
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.
- a tooltip
- that has to be made copyable
- by a context menu
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.
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.
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 ;)
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.
1. Your browser locale.
2. The developer's preference and ignoring the locale.
3. The server's configuration (so the operators preference).
4. Guessed based on your current network location.
I guess if you are in the US using a US locale it is usually true if you are visiting a US site as almost all of these will select a US locale so it doesn't matter the source, but it is impossible to be sure. And if you live outside of the US or use a non-US locale then at least one of these will frequently return a different locale and you will have little way to know which format is being used.
The month/day confusion is very real, but that isn't what parent complained about. In fact, if the site had used 4 digit years like 08/11/2002, as parent requests, it would still be equally confusing. So that was clearly not the point of contention.
Plus, consider using time tag, datetime attribute for displaying dates in a more accessible way. https://developer.mozilla.org/en-US/docs/Web/HTML/Element/ti... It's not so much different than a span tag in browsers yet, but why not making out webpages future compatible.
Please just give me your actual street address, and Google and I will figure out how to get there.*
*Except yes, Google gets many addresses wrong. Those are the exception.
The maps are constantly updated, whether google, apple, or openstreet. The perception of them being inaccurate unfortunately does not tend to update.
For the longest time they didn't even have the numbers of individual houses and treated the whole area as an atomic blob :shrug: A neighbor put the numbers into OpenStreetMap eventually and soon after Google Maps had then too.
For a while they still treated it as a normal road though which means "find route" was still unusable but you could at least use it as a map. Nowadays they have separate entries for the above-ground paths and it works.
EDIT: Please someone write "Falsehoods programmers believe about city planning"
> No human uses “less that 24 hours” as the definition of “yesterday”. Computers, unfortunately, do.
Is that right? I've never noticed anything using that definition of "yesterday". Plus, if anything within the last 24 hours were "yesterday", what would be "today"?
> No human uses “more that 24 hours” as the definition of “yesterday”. Computers, unfortunately, do.
At 9pm on Oct 14, 6pm on Oct 13 was > 24 hours ago, and people would still call it "yesterday".
Clearly it's confusingly worded so probably best if they just redo it.
But usually that's not the decision of the computer but the programmer.
It’s mostly to describe intervals. Usually in billing. You pay x/dygn for this, not x/day, even there it’s getting more rare vs x/24h.
This was mentioned elsewhere but it's buried under another comment. I think GitHub needs top level placement for this audience. I imagine a lot of us feel this pain from time to time.
Correction: computers programmed by programmers who believe falsehoods about time zones and dates do.
It’s entirely possible to unambiguously slide a timestamp into the local calendar of your user and from that determine what the local date offset is. If you just take floor(now - time / 86400) then of course you’re going to produce garbage.
Too bad “having too many options” is perceived as a bad thing by the current regime of aesthetics-first “designers.” It’s the only thing they hate more than using screen real estate for something besides seas of white space.
Where precision is needed (maybe finegrained transactions?) date and time might be better.
> Where have you seen a service describing something posted less than 12 hours ago as being "posted last week" rather than "posted yesterday"/"posted today"?
Every single time display library I have seen will do as the poster explained, and show more granular information the closer it is (generally starting at “X seconds ago”). Your technicality is certainly true, but a strawman.
This is literally a non-problem. If a library behaved in the way the parent commenter makes them seem like, then, sure, they have a point. But they don’t. Something that occurred a second ago would say “a second ago”. Something that occurred 5 minutes and 43 seconds ago would say “6 minutes ago”, etc. There is no library in the world which takes a timestamp a second ago and outputs “a week ago” and pretending like there is is, literally, a strawman.
Yeah, I've seen enough examples to know that no 2 websites implement the same logic so I shouldn't try to second-guess anything more than what the text literally says.
If you were told something was uploaded on 2023-10-02, with just the average feeling that we're currently around the middle of the month we'd know the video is roughly a week or two in the past.
Especially being from Europe: it is never clear if 10/04/23 means October 4th or April 11th unless you know which date format is being used.
Someone must have spoken up, because it's now as follows: the time(for today's email), "Yesterday", then the numerical dates.
On a tangent: Maybe one of our german friends can answer if the day before yesterday is displayed as "vorgestern", since that's part of the german lexicon.
Second tangent: While we're at it, can English finally standardise what "next <day>" means. For example I'm writing this on Saturday, and "next Monday" is permitted to mean either in 2 days time or in 9 days time.
But I realize that humans feel the need to do this and I like the way Reddit does it.
<time title="Sat Sep 9 13:06:15 2023 UTC" datetime="2023-09-09T13:06:15+00:00" class="">1 month ago</time>
with a title to show tooltip for casual interest, but especially important, the chatty time within an explicit TIME tag that allows parseable stamps to be saved with pages and mined regardless of local naming conventions.
Fortunately, if you hover over the relative date, it will expand to show the exact date time, but it would be nice if this were swapped.
Thankfully YNAB’s date picker is a little calendar so I can figure out the right date easily enough but it’s always jarring to see “Monday” after I’ve been looking at real dates for older transactions.
If the time is static on the page rather than dynamically updating in JS, for such small intervals it'll already be out of date by the time you scroll down to read it. But dynamically updating timestamps is irritating because it causes the content to "animate", and that movement catches the eye for no good reason, since nothing is really changing with the content (Reddit does this).
Due to clock skews you can even have the event come from slightly in the future, and marking that accurately like "2 seconds from now" would be even more confusing.
"just now" solves all these issues
I also concur with the author of the post saying "ago" is not enough. So the app has been updated to display:
fuzzy relative duration
hour:minute:second period timezone
full_day_name abbreviated_month_name day_number
[2] https://hexdocs.pm/timex/Timex.html#from_now/3
[3] https://github.com/hbcondo/last10k_liveview/blob/main/lib/la...
Mike Meyers deserves credit for trying to keep such language alive 30 years ago:
Phrases like this warm my heart too. While I abhor relative dates in general, seeing this in a UI can be a nice Easter egg.
I work from home, for myself, and I don't care what date it is and I rarely both with the date, and knowing something was about a week or a month ago is about as accurate as I need.
“Yesterday” is barely any shorter than the date in “yyyy/mm/dd hh:mi:ss”.
I've resorted to using "datemodified:this year -kind:=folder" on a keyboard macro and changing 'year' to 'month' or 'this' to 'last'... or using WSL to search.
One obvious problem here is that the number of files I search through changes with each season. January and February are the worst, because "last month" and "last year" overlap for one month, and then on February 1st, the query results are again exclusive. If I want all PDFs published in the past three weeks after returning from winter break, I need to use two search queries in Explorer.
Contrast that with Linux, where there are multiple standard, well-documented, reasonably easy to remember methods of searching by date, including within very specific timeframes---not just a choice of month or year. On the GUI side, GNOME Files has much more customizability and isn't any harder to understand than Explorer.
Just as the past decade has been a disappointment in home assistant progress, I had hoped in this present age, ANY reasonably query could be parsed, and optionally, the exact query shown as the machine sees and/or a plain-text standardized description of the search.
[<Ctrl> + F] "PDFs from the past three weeks"
↓
Parsed: find "//doc-network/rel/**/*.pdf" /createdafter 2023-09-24
Searching for all Adobe Reader documents (PDF format) created between three weeks ago and today in the current folder ("rel") and/or any subfolder.
You rarely need to process the precise dates. If the article or item is old, "years" is the perfect measure. You very rarely need to consider the precise day the thing was created on.
Most tools should simply show the date as a tooltip. I was just sharing this video [1] on another thread, and YouTube does it perfectly. Date shows up on hover.
If you're presenting records in a tabular format, then dates win. But consumer products are enhanced by relative time.
I highly disagree. A quick glance at an absolute date immediately gives me the general idea of when it happened. Most of the time I want to know the exact date to compare it to other dates. When I see a relative date, I almost always need to subtract it.
Putting the spotlight on the format optimized for the people who care the less feels odd. There's not much load on the brain if we just skip the info we don't care about.
You have to go to the video itself to get that tooltip, and the relative date is unreasonably vague a lot of the time. It's far from perfect.
Also, to be honest, I hate seeing times without timezone info. As someone often scheduling with people far away, it does not help me to have the calendaring tools silently convert times into my local timezone and display them unqualified. Particularly when everything tends towards a flat rendering style where it isn't always clear what is metadata from the system and what might be text written by the human far away.
Generally, I dislike when designs fixate on "simple" and blithely ignore real failure modes. I have to try to get into some weird headspace to imagine how the UX designers failed at their job so I can try to predict the right failure mode and recover what I can out of the tools...
Times are not universal. Displays are not always rendered at the moment the user observes them. Location of the observer is not always well known. Things fail. Doubly so with mobile.
If you have the exact absolute data, then just give me that.. in its original form. Unbelievable that people put effort into making it less precise and making relative. Why? Because it looks _cute_? Personally, I always find it hard and tiring to mentally process these and map it back to an actual point in time.
1 day 2 hours ago
1 year 10 months ago
2 weeks 3 days ago
If I want a picture we took, odds are high I will have a fuzzy recollection of when. At this point, "last decade," is probably pretty useful.
It seems to me part of this 'friendly' design and copy that is everywhere on the internet these days. You're not my friend, you're a tool, like a screwdriver or a kettle.
"It's a little before half past four."
If they don't have space for the full date and time, it could be "Fri 23:59".
* Displaying "October 13" for dates that are years old.
* The convention that published papers don't have dates on them. This is a convention from the days when papers came in bound journals with a date on the cover, so there was no need for a date on each article. Now they come as standalone PDF files with no date info.
And anything less than a week ago (but more than 24 hours ago) should just say the day of the week.
Why is it so hard to understand that the importance of the precision does not depend on the date or the event, the date is attached to, but on the activity of the reader. Therefore no rule a programmer can implement will be good in all cases. That leaves the developer with two choices: Let the user choose or display a complete date and time.
The best compromises make everyone equally unhappy.
Either that or "Wednesday about teatime".
/s
But seriously. Youtube: NOBODY cares whether a video is 2.46 years old. Github: slightly annoying, but 3 days ago is generally more useful if you have to choose only one.