Anything longer ago than yesterday should just say the actual date(grumpy.website)
grumpy.website
Anything longer ago than yesterday should just say the actual date
https://grumpy.website/1389
366 comments
I feel like there was a UI designer convention and they had a contest on the best way to hate on users with GUI microagressions and this "N days ago" trend won so now it's everywhere.
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 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!
Hah, like UI designers hold conventions...
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.
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.
I feel like they regulary do this contests and are only working in making UI more shitty every day.
IIRC this started in the Mac finder with OSX 10.2. It bled onto the web a few years later with the advent of UI frameworks and blog feeds.
Relative dates in Finder list view have been around since at least Mac OS 9.x, see for example this screenshot:
https://i.stack.imgur.com/bdY7i.jpg
> IIRC this started in the Mac finder with OSX 10.2.
I see proper timestamps in Finder in Date Modified column.
I see proper timestamps in Finder in Date Modified column.
IIRC the trend started with Twitter
Even more fun: everybody rounds differently. “1 year ago” may mean 365 to 729 days ago to YouTube, but another website thinks it means 183 to 548 days ago (nearest whole number of years), and another website 350 to 548 days ago (nearest whole number of months up to 11, then years), and another anywhere from 1-365 to 364-729 days ago (within the last calendar year).
Exactly, and I think we as humans also read it differently. To me "3 years ago" reads "sometime in 2020, who knows?" but it might be "October 2020" to someone else. It's so imprecise as to be rather useless.
One more significant digit solves this: 3.2 years ago
Except that saying "1.5 years ago" with a decimal would be 1 year and 6 months ago, and you won't want to do the conversions from a base 10 to base 12 for the month. Just write "October 21, 2020"
Which would be the worst date format.
Just use ISO 8601 (2020-10-21) and you could even sort by the date.
Isn’t it nice to see people deduct in real time why many sites use relative timestamps?
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.
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.
> Isn’t it nice to see people deduct in real time why many sites use relative timestamps?
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.
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.
ISO 8601 is a long document which none of us can read and which specifies A LOT of different formats, including 2023-10-21, +0020231021, 2023-W42, 2023-294, and a lot of others (including duration specifiers).
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.
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.
I would have no plan when this was. Just writing the fucking date is the best solution.
Oh, I was going to mention that one. We're in October 2023. A video published in November 2021 should not say "1 year ago" but rather "Almost 2 years ago".
Even better would be for it to say "November 2021".
What's wrong with 2021-11-21T15:10:35 ?
The T makes it hard to visually parse. Whenever I try to read a timestamp using the T I have to scan it very carefully to see the date-time boundary. It'sWasWifWweWusedWaW"W"WtoWdenoteWwordWboundaries. I beg you people, use a space:
2021-11-21 15:10:35
See how much easier that is?
2021-11-21 15:10:35
See how much easier that is?
I agree on the 'T' being harder to read, but dislike the use of a space as it makes it ill-suited for use in a filename, and would allow word-wrapping to occur between the two sections. I'd much rather they had used an underscore instead of a 'T'.
Does windows not allow spaces or something? Unix variants seem fine with it.
Windows does not allow the colon (":") in filenames, so you can't use the ISO date-time format in filenames anyway.
RFC 3339 notes:
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
RFC 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
Best to avoid spaces in file names even if the OS allows it (hell, you can put a new line in file names in Linux and I believe Mac OS but that's a terrible idea) because many programs will exhibit major error states if they end up processing these names due to assumptions about file names.
Best to combine a carriage return and tab.
irb> puts “2021-11-21\r\t15:10:35”
2021-11-21
15:10:35And thats the reason why we should use more spaces and other special characters in filenames at every public used places. Thats the only way this bugs of lazy and stupid software developers getting fixed finally.
The principled stance is nice (and I agree with it generally) but sometimes you just need to get work done and not have to rely on trying to get some developer to fix something. Fully agreed though that it's lazy programming if an application can't deal with spaces.
Macos allowing leading spaces in file/folder names made for some fun shenanigans on a school laptop with not great grep usage for blocking apps.
The reason for avoiding spaces in file names is because of broken bash scripts, that don’t quote their arguments. Meaning about 99 out of 100 of them.
Not that avoiding such names solves the problem, it just makes the RCE vulnerability more latent.
Not that avoiding such names solves the problem, it just makes the RCE vulnerability more latent.
Soundly like space-filled names would be a good best practice to force you to harden your scripts.
Programmers hate dealing with whitespace in strings with a burning passion.
Which I've always considered a weird anachronism, because 'space' isn't represented any differently than any other character, U+0020, unless you really want to get into the variety of "whitespace" elements. Same with newlines. It's all bytes.
There exist non-breaking spaces for that exact reason.
[deleted]
The “T”, mostly.
It's missing the time zone offset /cry
I had to fix so many of these in various databases and frontends, lol
I had to fix so many of these in various databases and frontends, lol
Why not just display it in the viewers' timezone?
Mostly because the browser Javascript API for Date is kind of crap for dealing with timezone info. There are some efforts to standardize on a better API, but it's going to take time to migrate.
How do you know what time zone to convert it FROM? Unlike epoch time (Unix time in milliseconds or seconds), "2021-11-21T15:10:35" doesn't automatically mean UTC without a "Z" or "+0" at the end. Without the time offset, that timestamp could be in any of the world's timezones. There's no way to know what moment in time was actually stored/meant.
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.
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.
Surely when someone posts content, that date/time that happens is captured by the server in epoch time.
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.
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.
How do you determine the viewer's timezone? A lot of apps try to find your timezone and it works fine until you travel abroad to a country with a different timezone.
If your own user-agent or OS is working on the wrong timezone, that's your fault.
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.
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.
Not used for display purposes though :-)
It's missing the timezone offset
Time portion not being useful I'd say.
[deleted]
I’d prefer it to use the month name.
Then it doesn’t matter if you write it
November 12 2012
2012 November 12
12 November 2012
2012 12 November
Etc.
Then it doesn’t matter if you write it
November 12 2012
2012 November 12
12 November 2012
2012 12 November
Etc.
If you're not formatting a numerical date in the user's preferred date format then you're probably not localizing the month name to the user's language either.
How would 2012 ноябрь 12 feel to you?
How would 2012 ноябрь 12 feel to you?
Fine if I set Russian as my langague. I presume Youtube does localization.
So it could also take the preferred datetime format from the locale.
It matters a lot if you try to sort on that column
We're talking about how it's displayed on the frontend, not how it's stored on the backend
One persons front end is another persons back end.
Especially if you're a proctologist.
I think irrational’s point is that it’s trivial for any viewer, no matter the locality, to identify the date if there is no longer any ambiguity between date and month.
ISO 8601 is so annoying because timezone offsets are now no longer implied
I thought ISO 8601 allowed both unqualified times (e.g. "2023-10-14T19:21:45"), which are assumed to be local times, and qualified times (e.g. "2023-10-14T19:21:45−01:00"). Which one is used is then a choice left up to an individual program.
I prefer stardate
I prefer parsecs since a long long time ago.
But I don't mean to pick a Star Wars / Star Trek fight: I'm bistellar, I love both of them!
But I don't mean to pick a Star Wars / Star Trek fight: I'm bistellar, I love both of them!
[deleted]
There, even better: 21/11/2021
No: 1) unfortunately ambiguous with also widely used MM/DD/YYYY, 2) cannot be naturally sorted, the order does not go from the most significant to the least significant, especially when appended with HH:MM:SS.
Sorry, can't sort it in a column. I'm totally uninterested in everything that ever happened the first of january. I want to see the mails from last night on top.
Where's the fun in that? Let's design heuristics that work culturally in some parts of the world and be imprecise instead!
It’ll even round down when it’s the same day.
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.
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.
The imprecision could be fixed by forbidding the first digit from being 1, switching to a lower unit instead. So up to 120 seconds ago, then up to 120 minutes ago, then up to 48 hours ago, then up to ~61 days ago (ick, months are evil), then up to 24 months ago.
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.
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.
"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."
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.
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.
> 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.
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.
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.
Not to mention, it is a lot easier to program a function formatting the text to exact dates than writing a function that estimates how long ago it was.
I was just thinking about that the other day..
> File last modified: the other day
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.
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.
But of course "lunchtime" is a completely meaningless term for me.
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.
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.
Would you still be upset if I told you it has a hobbit setting where you get times like "second breakfast" and "elevenses". I'm sure you're a cool person and I don't want to denigrate your lifestyle, but the thing I'm talking about is a humorous desktop widget on an eopen-source desktop. You are certainly not obliged to use it, I'm fact you could even send in a patch that represents you - and have "only meal of the day time - ish" or "time to not attend a religious service".
If only I had explained the purpose of the church example was to illustrate with a stronger example that's merely further along the same dimension... If only I had explained anything at all instead of just saying I hate some idea for no unpackable explicable reason...
If the thought of a clock that says "about lunch time" sends you into a seven paragraph manifesto about the evils of the clock.....perhaps you should just not use it.
Exhibit A
Could even be personalized so the date appears as "the same weekend you and Charlie went out on the boat"
Funnily enough google collects enough data for that to be possible
That's precisely the joke, why bother restating it?
My old phones' timer said "Less than 1 minute" instead of saying 59 seconds... Everything less than one minute whas "Less than 1 minute".
I've seen that to avoid numbers that would go out of sync the moment they we're displayed, because it was better to be imprecise than to be wrong
But this was a timer on a normal phone. It's pretty useless to tell me it's less than one minute left until the eggs are done. Do I have time to do a bit more dishes or will the phone ring in one second? Who knows?
Interesting you say that actually, I have been working on a folder synch implementation across samba with mac & win environments and the last modified times are not a reliable source of truth it seems. This fuzzy method would have been very useful as the exact minute of the modified file isn't critical.
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!
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!
Getting off topic but most sync systems do a quick comparison then a full one.
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.
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.
> So for example check modified, inode number against the previous version.
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.
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.
As long as its configurable - all fine.
> I was just thinking about that on 2023-10-10
FTFY
FTFY
I sometimes really wonder who the heck greenlights such horrible UX at Google.
How can I upvote this enough.. Luckily, often the timestamp is visible as a tooltip.
Case in point: When you browse npm versions of packages, it will date them with "version 5.3.27 was released 'about a year ago' craziness. ARE YOU PEOPLE OUT OF YOUR BLOODY MIND?
i am browsing through older packages to figure out the order they were released in, to sketch a pinning of compatible packages to form a build configuration, and 20 sequential packages are reported as 'about a year ago', requiring me to tooltip each one to figure out which ones are too recent to use.. The crayon eating has gotten out of hand.
Brought to you by the same morons who build ORMs that map table names between (irregular) singular and plural. To serve what need..
> Luckily, often the timestamp is visible as a tooltip.
What? Really? Checking ... yep, indeed, Youtube does have such a tooltip. How come I didn't know that? Thanks, that's very useful.
What? Really? Checking ... yep, indeed, Youtube does have such a tooltip. How come I didn't know that? Thanks, that's very useful.
yeah, common pattern, even works on HackerNews. It's nice when you need an exact time down to the minute or second.
But Hackernews for stuff older than a year (maybe slihtly younger) does indeed just show the exact date for a post.
But Hackernews for stuff older than a year (maybe slihtly younger) does indeed just show the exact date for a post.
However, on mobile iOS Safari there’s no standard way to trigger a tooltip that I’m aware of.
>The crayon eating has gotten out of hand
Beautifully put.
Beautifully put.
> ARE YOU PEOPLE OUT OF YOUR BLOODY MIND?
No, they’re just stupid, or at best, ignorant to a degree that makes them incompetent.
No, they’re just stupid, or at best, ignorant to a degree that makes them incompetent.
> ARE YOU PEOPLE OUT OF YOUR BLOODY MIND
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...
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...
I would go even further: I would remove these rounded, relative timestamps altogether.
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.
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.
Even worse is the stupid timestamps on notifications. If you don’t catch it within an hour it becomes imprecise (1h vs 2h ago). Maybe I really need to know exactly when that notification came in! And there is zero way to tell. Just give me the time! I can tell time.
One benefit with Thunderbird. It's still saying the exact date and time (knock on wood). If it's today, it only says time, anything else you get full date and time.
If they used absolute <time> the browser could format it to our preference (which varies).
https://developer.mozilla.org/en-US/docs/Web/HTML/Element/ti...
https://developer.mozilla.org/en-US/docs/Web/HTML/Element/ti...
The dream of a web where the server simply sent data, and the client chose how to display it, is totally dead. Web designers want their websites to look a certain way right down to the pixel, and client-side display control messes that up. To be clear, it's not that you can't still do it, but the website is never going to be designed for it and actively help you.
This is just one symptom of the advertising-supported web. The web was intended to inform, but modern websites are designed to impress. Personally, I'm more impressed with websites designed to inform, but the average person apparently isn't.
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!".
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!".
>The Semantic Web failed for the same reason: Humans click on ads but computers don't.
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.
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.
I understand your point, but I am incredibly suspicious of the ad market. For that reason, I do not believe that more people than computers click on ads.
My degree is in marketing so I used to offer human versus bot click analysis as a service. The initial sale was very easy but the practice was more like grief counselling than consulting. As a result, my customers weren’t sticky - they were happier before me. And I don’t believe anyone actually changed how they bought ads as a result.
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…
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…
I can totally believe your conclusion there. I worked for a digital ad agency back in the 2000s and was repeatedly told not to add conversion tracking before things went out to clients because everyone involved knew the numbers would be utterly damning. Half the time I think the only people who looked at the sites we were building were us, and the client team that was paying for it.
>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.
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.
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.
The semantic web and advertising web aren't mutually exclusive. The issue is that the advertising web, which optimizes for human attention, is necessarily going to get more human attention.
> Web designers want their websites to look a certain way right down to the pixel
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.
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.
And yet people will load a megabyte of JavaScript just to create a date picker that looks nice while you need about 20 characters to get a bugfree one in HTML: <input type="date">
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.
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.
TBF the default date picker in browsers is borderline unusable: it's very small with extremely tiny click/touch targets
> The dream of a web where the server simply sent data, and the client chose how to display it, is totally dead
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 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 did you have such a web?
When I was using The Proxomitron to rewrite incoming HTML on the fly. :p
When I was using The Proxomitron to rewrite incoming HTML on the fly. :p
It's really been downhill since the BBS.
What does that actually look like for the average viewer. In the examples the output in iOS/safari is as if the tag doesn’t exist.
Looks to me that it's a semantic-only tag that doesn't change the text on the screen at all. The GP is just incorrectly assuming it's something different.
I have no idea what a browser supporting it even means. Browsers aren't supposed to do anything with it.
I have no idea what a browser supporting it even means. Browsers aren't supposed to do anything with it.
This is correct. It would be nice to have an option for the browser to format it for you. Especially since you can't reliably get the user's time zone on the server.
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)
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)
Likewise on Firefox, doesn't seem to do anything despite the compatibility table saying it does.
One aspect that is so disturbing with the fuzzy display is when the day of the week is the most relevant info.
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.
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.
GitLab team member here.
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...
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...
I'm waiting for the day when I can additionally configure "use ISO8601/RfC3339 timestamps"
Not only on GitLab, but everywhere. In any application. On any website. It's a pain in the ass on Linux.
Not only on GitLab, but everywhere. In any application. On any website. It's a pain in the ass on Linux.
>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.
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.
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.
Oh, works here. I set locale format to German (Germany) or (Austria) while using Windows with English language. All date/time/currency formats are sane.
But you could also customize the region settings in "Additional settings...".
But you could also customize the region settings in "Additional settings...".
Good to know there are other countries with sane defaults. (-:
God yes. That should be just the locale. I have it set up right because `date` shows it correctly but nothing else respects it. Not Dolphin, not Thunderbird, not git.
For some insane (=AM/PM) reason the language is tied to time preference.
Worse, there are clearly conflicting sources of truth involved.
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.
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.
Throwback to when Google maps randomly chose to use km/h configured in android settings and "mph (auto)" from google account setting at once on the same screen in the app.
Thank you for supporting this. Anyone know if GitHub has a similar option?
Why isn't this the default?
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?!
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?!
I wrote a Greasemonkey script to replace Jira's useless time labels with the full date, including the day of the week. Highly recommend doing this for any browser-based software you use regularly.
I don't use Jira but suggest sharing it on GreasyFork for those that do.
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
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
Ooh, I'll see if I can do that this week.
I think I'm at 8 different greasemonkey scripts to manhandle Jira.
> I actually have a hard time imagining a scenario where a fuzzy date is more helpful than the exact one.
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.
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.
Date calculations are really easy for most people. Even in this case I just think I would be annoyed.
> I actually have a hard time imagining a scenario where a fuzzy date is more helpful than the exact one.
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 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
Thanks, this is one I am 200% behind. Youtube does this well too, knowing that a feed will start in 5h or 2 days is more helpful than the exact date I'd have to calculate from today.
I think that's the proximity and actionability that makes the difference.
I think that's the proximity and actionability that makes the difference.
The worst application I use about misrepresenting timestamps is gitg.
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.
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.
> ... screenshot ...
And screenshots are, IMHO, one important reason it should always be the full date.
And screenshots are, IMHO, one important reason it should always be the full date.
Outlook webmail is pretty bad. Not only does it do the "... days ago" thing, but it wants to show what it regards are important at the top. So you get two partly duplicated lists, partially shuffled together - it's horrible x 2.
Also that git timestamps are localized to each individual developer and are not validated, it can make global development more difficult. https://alesnosek.com/blog/2017/01/02/git-getting-the-timing...
I'm surprised that there seems to be no way to configure gitg to always show full datetimes.
Wow, what the screenshot is showing is a candidate for a professional misconduct if we had a governing body.
Just have both:
- An hour ago (15:47)
- Last week (MON 12 SEP 9:20)
- Two years ago (WED 14 APR 2021 11:47)
In frontends I’ve found it useful to have
- 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.
- 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.
Ugh, I pretty strongly disagree. This has become a common pattern in UIs, so I'm used to it now and I expect it, but I still hate it. At least for me, I agree with the article, I always prefer an exact date over "3 weeks ago". So why make me hover over a tooltip?
Also, I find myself needing to copy and paste information like this every now and then, which a tooltip is horrible for.
Also, I find myself needing to copy and paste information like this every now and then, which a tooltip is horrible for.
why? screen space.
"37h" is much short than the date and time of 37 hours ago.
of course, if you write out the age like "37 hours ago", that isn't as useful.
software doesn't _have_ to do it badly. the most recent version of this that i wrote will say it is Xmins old, but switch to the next unit after reaching 2*next-unit worth of time, so >120mins starts at 2h. then you get to 2d, 2mo (months), 2 years.
you can get the full datetime on hover.
all this is only in an object listing. when you open an object, you'll see the full date.
Screen space??
We have such large screens now, and yet most of these UIs are much more minimalist than any UI was 20 years ago when most of us were on 1024x768 or maybe 1280x1024 at best.
There is zero space excuse for this. It’s simply a fad, born from the Jony Ive fetish for form over function.
Also:
- 2 years ago
- 2021-12-31
How is that a space issue?
Also:
- 2 years ago
- 2021-12-31
How is that a space issue?
>We have such large screens now, and yet most of these UIs are much more minimalist than any UI was 20 years ago
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 .
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 .
Just wanted to say that I put them on two lines to measure them, to illustrate that a simple date stamp is the same if not more compact. I think the relative one is bad, and at best should be the one stuck into the tooltip.
No comment on dates, but my phone has a higher screen resolution than my laptop. That doesn't mean it has more space for UI elements.
I come back to the same page in 2 hours.
2h ago is now wrong unless it refreshes
15:35 is still correct.
2h ago is now wrong unless it refreshes
15:35 is still correct.
Alternatively, the actual date can be rendered on the page and if people want the relative they can hower over.
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.
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.
Another thing about the tooltip is that it makes it harder to copy and paste. At my work I need to copy exact timestamps for postmortems and other investigations, especially to correlate with metrics. For some web pages I have to go to the page source to finally get the fully qualified timestamp.
That’s true, though arguably it would be possible (and useful) to add copy-ability to tooltips (by context menu for example).
So, instead of providing a date on the page we've now arrived at
- a tooltip
- that has to be made copyable
- by a context menu
- a tooltip
- that has to be made copyable
- by a context menu
This is about when you want to have both representations (either can be useful depending on the situation) but don’t really have the space to display both (such as for comments here on HN). This is why tooltips exist at all, to display additional information that you don’t want to be displayed all the time. In addition, I’ve been wanting to copy the contents tooltips in other situations as well.
I agree and enjoy this, but I'm old and use mostly a computer where I have a mouse to hover with. I don't even know HOW to do that on mobile.
Long-press, usually, which kind of conflicts with right click at the same time...
Not sure at all about tooltips/hover.
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 ;)
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 ;)
I want actual time stamp / date format rendered on page. The relative is completely useless and I do not want to have to hover over everything to see the dates.
Just use the date. Enough of this nonsense.
What about on mobile?
If it's not a link then open the tooltip on tap.
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.
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.
Long press brings up tooltips in iOS. Perhaps in Android too.
That's only if the text isn't also a link. For example, on hacker news, the time is also a link. So long press shows the preview of the link instead of tooltip on iOS.
Make it a “hidden” link or something like on discord maybe?
Edit — I’m not a frontend dev. I shall defer to their expertise in said matters.
Edit — I’m not a frontend dev. I shall defer to their expertise in said matters.
I used to put exact time/date information into tooltips, thinking "the users that need it can find it without overloading the UI". I ended up undoing a lot of that a few years later when user interviews demonstrated that hyperlink-style underlines was insufficient for users to think "mouse over this".
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.
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.
i'm "underdotting" anything that has a tooltip (simple css style). most buttons have a tooltip with a sentence explaining what it does/how it works.
but this is in webapps that people use relatively intensively, so they can get used to this. it's better than desktop apps that often have no indication that hovering will show a tooltip.
Approximately two thirds of my time on the internet is spent without a mouse, so probably not.
You need to tooltip it without underlines... Maybe you did but couldn't tell from your comment.
Without underlines makes the data even more hidden. The style looks nice and clean to expert users, but I don't expect any of my less-savvy users to actually find it. (Though I could be very off-base as I've never A/B tested tooltip hinting.)
Dotted underlines are an old convention for "there's a tooltip here". Don't see it often anymore though.
Why? What's wrong with just the date?
An actual usecase:
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
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)You can set your preference to display exact times in GitLab. See my prior comment: https://news.ycombinator.com/item?id=37881456
Thanks - appreciate the pointer. My point though is that there are times when I want both.
It would be nice if the OS/Browser could detect a date, and calculate those for you, wheresoever it saw it.
Of course, this brings up that text date strings are often vague/could have multiple interpretations.
Of course, this brings up that text date strings are often vague/could have multiple interpretations.
If web developers would just start using `<time>`, we might someday reach such a reality.
Obviously when I said "just the date" I mean the full date time stamp, which is the thing we're discussing.
It significantly reduces mental exertion to have the calculation performed for you!
The problem with this is that the dev cannot know which calculation I need!
Right, and that's the case with every feature implemented in software. Showing both the precise datetime of creation and a "human readable ago" seems to cover a lot of bases that users seem to like, though. Recall, we're commenting on a thread that's proposing removing a feature that already exists (so presumably people want it).
The idea of rendering relative dates instead of the actual dates caught up about 10 maybe 15 years ago (a relative date here, yes).
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 :)
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 :)
What are some situations where you find calculating the relative date useful?
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.
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.
we're talking about a casual context, so the average user doesn't need an exact time stamp on when a picture was taken. The average person doesn't talk in time stamps, so the paradigm was shifted to display how people communicated.
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.
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.
"Significantly"? Are you sure?
Because oftentimes you think in chunks of time not dates. If a meeting is in 3 hours in instantly know what kinds of things I can do before that meeting. If a meeting is at 4:45pm. I have to know the current time, calculate the difference then I can start planning my time.
Seriously? Your complaint is that you have the extra mental overhead of having to know the time?
For the average person, yes.
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).
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).
You know, you can dumb down stuff too much.
But if I am travelling it is even more error prone for my computer to compute the correct difference.
But if I am travelling it is even more error prone for my computer to compute the correct difference.
The main complaint in this thread seems to be that the chunks of time reported are misleading.
Almost every device you're viewing the web page on has the time showing in a corner (which, come to think of it, is surprising, by now I would've expected UX "people" to have ruined that too for everyone).
This is exactly the distinction that needs to be drawn:
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.
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.
I have current time constantly on the right bottom portion of the screen. I do know the time literally any time I want to.
There’s this wonderful thing called a “watch”…
I don't usually remember what date it is.
Sometimes relative time is more user friendly or more accurately answers a question.
Sometimes I turn my math brain off
Also: include the year. I’ve been bitten so many times by web forums not showing the date on comments (“5 Jul”), only to find the comment was written years ago that I no longer even trust dates without years. I find myself hunting around to try to get a year to be shown to me if it’s not there upfront.
Also: use 4-digit years. There is a forum that I visit a few times a week. It's been around for 20-30 years. It prints dates as 08/11/02, 09/03/04. Very confusing
not sure what the confusing part is here? 02 = 2002.
You are assuming an American date format. The format of the date may come from
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.
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.
Is it Aug 11 2002 or Nov 8 2003 or Nov 2 2008?
I have never seen 2 digit years being used in YY/MM/DD formats. So I have pretty high certainty which place is the years.
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.
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.
"1 year ago" may not be precise enough, but "11 months ago" often is.
When implementing such a function we tend to avoid "1".
Instead of "1 week ago" it is "6 days ago"
Agree, when they are archived like in (google or web.archive.org), they will be relative to the indexing date if the label isn't calculated in client side, probably the javascript won't be working well in archive though.
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.
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.
This is an issue in the spatial domain too. Whenever somebody invites me to their house I ask them "what's the address?" and they inevitably proceed to give me a long verbal list of relative directions: "Go east on highway 10 and take the first exit, then turn left, go two blocks, and then turn right." There are a thousand ways this can go wrong. Errors compound.
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.
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.
Almost every address where someone says "google gets it wrong" is simply not accurate. Mapping software was right every time.
The maps are constantly updated, whether google, apple, or openstreet. The perception of them being inaccurate unfortunately does not tend to update.
The maps are constantly updated, whether google, apple, or openstreet. The perception of them being inaccurate unfortunately does not tend to update.
Google Maps used to be really bad in my then neighborhood which had roads and garages underground and bike lanes and footpaths on the ground level.
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"
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"
I don't like these unnecessarily-fuzzy dates either, but:
> 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 “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"?
I personally use "yesterday" for anything before when I last slept. Yesterday can easily be technically today, but just in the late night before I went to bed.
I don't think it is right. Moment.js for instance, does not work this way. It uses the calendar day definition of "yesterday". Times between the immediately preceding midnight and the midnight before is considered yesterday.
Swedish has two words for day. "Dag", same as the english "day", and "dygn", meaning "24 hour period". I'm not sure if you can use it in the way the author suggests that no human does, but maybe?
But it’s hardly ever used to represent time offsets in conversational language, especially not backwards in time, only occasionally forwards.
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.
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.
Ah, good to know. I'm still learning the language and haven't gotten much into detail with talking about time.
[deleted]
I think it doesn't mean everything within the last 24 hours is yesterday but everything before the past 24 hours isn't yesterday anymore.
But usually that's not the decision of the computer but the programmer.
But usually that's not the decision of the computer but the programmer.
I think they meant "more than 24 hours" rather than "less". It makes more sense in context.
It's still not right though. People will say at 9pm "I did it yesterday" about something they'd done the previous date at 6pm
I don't think they're saying it can't be more than 24 hours just that it can be less.
Clearly it's confusingly worded so probably best if they just redo it.
Clearly it's confusingly worded so probably best if they just redo it.
agreed completely - "yesterday" usually includes times both greater than and less than 24 hours ago. People usually just mean… some time in the date previous to now. Roughly.
I think you switched around your sixes and nines.
I don't think I mixed it up
> 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".
> 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".
Anything in the next 24 hours, obviously.
GitHub is my worst offender. When I need a timestamp for Git I always need the exact date and time, even if it's recent.
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.
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.
> No human uses “less that 24 hours” as the definition of “yesterday”. Computers, unfortunately, do
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.
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.
On a related note, I dislike when time zones are omitted from displayed datetimes. I have to guess: Is it my client's tz, the server's tz, UTC, or something else?
I'll leave my chat program open for two weeks and it says the message was received 'yesterday', even though it was actually two weeks ago but hasn't updated because it's just been sitting there idle. Anything other than the actual timestamp is utterly useless.
That particular point is an implementation issue, however. There are web forums I frequent where the time indications update in realtime while the page is just sitting there.
Does this also work in a screenshot?
In the other direction (and on a different scale) I hate it when the bus-schedule app I use tells me that my bus leaves "in 8 minutes". Ok, I'll put on my shoes and jacket, check if I have all the stuff in my bag - darnit, I forgot my book, can I spend a minute searching for it and still catch the bus? I check the time, which is 9:57, and I remember that the bus leaves... 8 minutes after some unspecified moment a few minutes ago.
I actually really hate fuzzy date displays. More often than not I want to know exactly when something happened and 2 hours ago isn't usually good enough. Just tell me the exact time I'm a smart guy I can figure out how long ago that was.
It’s interesting here in that there’s a sizable group (looks to me like 25% but let’s be generous and assume 50%). Seems like the kind of thing that should 100% be a user preference.
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.
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.
We'll I'd much rather see "posted last week" where precision isn't needed over having to look up the date in the calendar.
Where precision is needed (maybe finegrained transactions?) date and time might be better.
Where precision is needed (maybe finegrained transactions?) date and time might be better.
The problem is that on Monday morning "posted last week" could mean it was posted less than 12 hours ago, or almost an entire week ago.
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"?
The point is that both are technically correct. At 12:00am on January 1 that happens to fall on a Monday something that occurred 1 second ago can be considered to have taken place: last week (depending on when you consider weeks to start/end), last month, last year, yesterday, etc.
Sure, they’re both technically correct, but that wasn’t the question. The question was
> 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.
> 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.
Actually, it's that question that is the straw man. jstanley's point is that to the reader "posted last week" could mean almost no time at all ago. It's not about the display library choosing to label recent things as this. It's about humans reading such a label and not receiving the intended information, because humans don't cut off what they understand "last week" to mean at some arbitrary 12-hours-ago mark.
Except they do get the intended information. The label doesn’t exist in a vacuum; the user would have seen other examples showing the specificity at intervals other than “last week” which sensitizes them to the cutoff points.
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.
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.
> the user would have seen other examples
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.
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 the user needs to know the details of your "time display library" to disambiguate "last week" then you've already lost. It's bad UX. Stop doing it.
But… users don’t. Literally no library out there does what the parent commenter claims they could do. They all use sensible cutovers for relative dates.
The point is that if a user sees "last week" it's ambiguous. They DON'T KNOW that your libraries don't behave that way. All they see is "last week". Are you really not getting this?
Most of the date libraries that do relative time formatting like this would use hours if it were hours ago.
At the "last week" level, assuming we don't keep track of today's date, wouldn't it be good enough to see in the date if it's in the same month or not, and eventually see if it'rougly at the beginning, muddle or end of it ?
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.
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.
If precision isn't needed, why do you need to know it was last week? Why can't the precise date be displayed for those who need it?
Exactly. A video on YouTube posted '1 month ago' is not the latest episode I'm looking for. Much quicker to interpret than a timestamp. Sometimes a fuzzy date is enough.
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.
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.
Agree. I also like the relative dates. E.g. on Github where it’s useful to get an intuition very fast of when files in folders/projects were last updated. I don‘t care about the actual dates in this moment, the fuzziness of the relative date is the approximation I‘m looking for.
So instead of preferring actually locale-aware date formatting you would prefer fuzziness?
If it's December 25th and something says "December 20th", so you really have to look at a calendar to know when it was, relative to today?
Why would you need to look up lasts week date on a calendar
How do you know where precision is needed?
I'm glad I'm not alone in this, Apple's Mail app used to display Monday/Tuesday/Wednesday/etc for the last week of email before switching to numeric dates. It would drive me crazy as I mentally work with dates and having to constantly check "ok what date was last Tuesday", "ok what date was last Saturday", introduced needless complexity.
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.
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.
My favorite is when I see a photo posted to Google maps "1653 days 5 hours ago"
/u/epistasis said it best: “UI is communication, and UI designers have decided that mumbling is cool.”
Unclear communication increases repetition and confusion, which can be creatively interpreted as engagement, increasing ad revenue.
It doesn't increase ad revenue. It increases scores in A/B tests which is believed to predict ad revenue. Should be an entry in "Falsehoods project managers believe about A/B tests".
This is my biggest complaint when i reflexively type `git log` to get some context on a branch.
There's a `--date` flag which you can use to control this behavior. Also, it depends on your git configuration.
I'm grumpy too... and I think pages that have chatty dates and do not contain embedded parseable dates/times at all should be shot with a poop gun.
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.
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.
Github does that and it always makes it very difficult to understand when something was actually done/committed.
Github was the first thing I thought of when reading this. My only use case for the commit date is to quickly check if a certain commit merged before a branch was automatically cut, so I need the day of the week and time, not "11 days ago."
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.
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.
Yup, agreed. I came hear looking for this one. Whenever I need a timestamp in GitHub I need the exact time. I always have to hover to get the info I need.
Seriously, of all the platforms that do this pattern, this one is the most user hostile.
Apple Wallet/Card is so annoying with this. It puts dates on transactions over a week old but within the last week it says “Wednesday” (DOW) or “Yesterday”. I don’t use my Apple Card for a lot since it doesn’t automatically integrate with YNAB and it’s always a pain to enter those transactions.
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.
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.
This isn't just a "problem" with computers and fuzzy "<time ago>" labels. Humans do this, too. The worst is when people use inappropriately long periods, for example when a reporter says something like "Joe Criminal was convicted last month of XYZ", when "last month" means some time in the previous few days that happened to fall in the previous month (this kind of thing happens a lot). It takes more effort to come up with that bullshit than to simply be more precise.
Everything should just say the actual date/time. The “longer ago than yesterday” bit is the slippery slope. It’s never acceptable. If it’s not configurable, it’s always the wrong idea.
I have a slightly related problem: infinite scrolling as the only way to access the archive. Like, imagine I want to know what some blog/media site posted during some important historical event, and there is no pagination or calendar to pick. Or am I just using the web wrong and there is some way? Example: https://www.astralcodexten.com/archive
This kind of thing is especially egregious on the GitLab UI where,
for example, something was committed “a moment ago”, “just now”, or some vague shit like that.
That one makes perfect sense to me, as if it said like "1 second ago", this would almost always be a wrong statement due to differing clocks, and the time taken to render and send you the page.
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
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 recently came across this conumdrum myself when developing a live streaming web app[1]. The app formats a DateTime using a fuzzy relative duration[2] which displays "1 minute ago", "2 days ago", "yesterday", etc...
I also concur with the author of the post saying "ago" is not enough. So the app has been updated to display:
[1] https://live.last10k.com
[2] https://hexdocs.pm/timex/Timex.html#from_now/3
[3] https://github.com/hbcondo/last10k_liveview/blob/main/lib/la...
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
[1] https://live.last10k.com
[2] https://hexdocs.pm/timex/Timex.html#from_now/3
[3] https://github.com/hbcondo/last10k_liveview/blob/main/lib/la...
I’d be happy if articles included at least the year. So many times I’ll come across something, and have no idea how recent it was because there’s no date whatsoever.
Agree with the sentiment, but I'm sad that meaningful words like fortnight that once colored language are mostly archaic.
Mike Meyers deserves credit for trying to keep such language alive 30 years ago:
https://www.imdb.com/title/tt0108174/characters/nm0001439
Mike Meyers deserves credit for trying to keep such language alive 30 years ago:
https://www.imdb.com/title/tt0108174/characters/nm0001439
"Fourscore and seven 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.
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 like the imprecise date, especially when they have the eact datetime, down to the second, in a ABBR title, which is clickable on mobile.
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.
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.
For my work I use the following simple design: display the date and when you hover it tells you how many days ago it is etc. I initially had it the other day around, but users complained and said the date was more useful. I hate websites that don't even give the date on hover.
A lot of these "UI Features" are just annoying. the worst one is cutting off the ends of Tex...
I absolutely hate that recent versions of Outlook (at least in a Mac) shows “yesterday” in the date field in emails. I get hundreds of dates per day, show me the bloody time too! And this is not configurable!
“Yesterday” is barely any shorter than the date in “yyyy/mm/dd hh:mi:ss”.
“Yesterday” is barely any shorter than the date in “yyyy/mm/dd hh:mi:ss”.
Yup. Configurable went out the window about the same time using any native UI widgets or windows did. One 24-year-old “UX designer” will decide the single best way for everyone in every situation, and their decisions are final.
The reporting of a message's timestamp really depends on the system you are working on. And the key aspect is to genuinely think how the users think about that timestamp.
I recently implemented it in a real time system where I write things like
"just now" (within the last 10 seconds)
"more than 10 seconds ago" (between 10 seconds and less than a minute)
"more than a minute ago" (between 1 one minute and less than 10 minutes)
"more than 10 minutes ago" (between 10 minutes and less than 1 hour)
... (I think you get the gist)
After it say more than a day... then that's it the message is considered very old
I remember when I had to use Jira for the first time, which had this "n days ago" display for the tickets. I don't remember if that couldn't be changed or the person in charge just could not/would not do it, but I needed the proper dates often.
So I wrote a basic user script which would read the actual dates out of the title (at least the date was in there) tags and then replace the unusable default output with it. I put that in button on the bookmarks bar and over time, several people saw it and adopted my solution.
I never met anyone who liked the "human readable" format more that the actual date.
In Windows Explorer, it's always a mystery if my date specifier is valid. I would often forget a colon or use the wrong flag name or accidentally use a leading dash as most command line flags would accept. When there are then no search results, I mistakenly assume the document I want hasn't been uploaded yet. I email a colleague, they reply it's in the network drive as anyone in the organization would expect, I look like an amateur.
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.
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.
I disagree. Delta time requires less computational load on the brain.
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.
[1] https://www.youtube.com/watch?v=WqZLkzdNYuI
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.
[1] https://www.youtube.com/watch?v=WqZLkzdNYuI
I'm surprised nobody in the comments (that I can find) has mentioned another problem of relative times: am I the only one who considers of the ambiguity of _when_ was the page rendered and therefore what is the reference point for the relative time?
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.
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.
> Delta time requires less computational load on the brain.
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.
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.
> YouTube does it perfectly. Date shows up on hover.
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.
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.
I would actually point to YouTube as a bad example. YouTube refuses to make the absolute timestamp available unless you actually navigate to a particular video's page. That makes it impossible to see which video uploaded "X period ago" is more recent from e.g. a search result page. Even if you don't _usually_ want an absolute timestamp, there's no reason to make it completely inaccessible in most places.
The main issue to me is the asymmetry on how much it really matters when date need to be precise, vs how how little it matters the rest of the time.
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.
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.
Maybe. Usually, relatively recent deltas are great which is mentioned in the article. They are less ambiguous enough to be helpful. But longer the deltas are from NOW, the higher is the cognitive overhead in my experience. And interfaces should reduce the overhead to make life easier for people.
The compromise is to have the actual timestamp as a tooltip, and/or have a click/tap toggle the representation. But yes, it’s often annoying to only have a vague “3 months ago”.
I like how apple photos does it. It's today, yesterday, then day of the week name (tuesday) and then the date after you pass the 7 day threshold. And they always put in the time
Whatever fancy misguided millennial time encoding your planning to use, display the actual time stamp as well (yes with TZ) for the rest of us. Plenty of screen space these days.
Maybe I’m in the minority, but if you’re ever not going to display the actual date, put the exact date/time in a nice, readable tooltip, or otherwise surface a way to see/copy it on right-click. I feel like some of this could be highly customized user agent settings. Always send the most precise data to the renderer and let it render how the user wants to consume it. By default, that could be how you want them to see it, but don’t get in the way.
I find these imprecise, rounded, relative timestamps very irritating and I am so happy to see that I am not the only one.
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.
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.
Thank you for this. I actually thought it was only me that found these kinds of "timestamps" much less useful more often than not.
This depends on how important the precision is. "1 week ago" can be fine (for blog posts), or it can be stupid (for news articles).
JIRA/bitbucket: something that really pissed me off. It was early January. I was in a rush and needed to know if some commits deployed a few days ago, 1 week ago, or 2-4 weeks ago, or never. Nothing overly specific. I get to the specific page for it. All of the deployment dates say something completely useless like "last year" or "a year ago".
Why is nobody mentioning using a tenths decimal, like 1.1 days ago, 1.9 years ago, 2.5 weeks ago. That’s how I like to implement it!
Instead of a decimal place I like to use the next smaller unit, i.e.
1 day 2 hours ago
1 year 10 months ago
2 weeks 3 days ago
Meh. You should be able to get to the date, but relative times are super useful. Especially as inputs. And realize relative dates are calendar specific. Last week could be just 12 hours 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.
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.
Yeah. For emails I use display time stamps extension:
https://chrome.google.com/webstore/detail/display-email-time...
I disagree. I don't know what day it is, have to check and I dont want to run this computation even if I knew without checking. Likely this is preference thingy, you prefer precise, I prefer convenient.
If I added up all the seconds I've waited hovering over a GitHub date waiting for the proper timestamp...
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 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.
Does anyone remember text clocks from decades ago.
"It's a little before half past four."
Since everyone here seems to be screaming for absolute dates, let me say the opposite. Whenever I look st a timestamp, 80% of the time I’m interested only in how far back that time was relative to today. Relative timestamps are great for at a glance viewing.
At minimum it should say Friday Morning. Glad someone is fighting back on this practice.
Gitlab gets me with this every Monday morning. I see someone did something "two days ago" I think "they worked the weekend?" I hover over the date and realized Gitlab thinks Friday afternoon was two days ago.
You can actually (finally!) turn this of in your preferences and see exact dates.
I have given up on all hope of UI/UX getting better on general consumer devices. The downward trend started since smartphone became mainstream.
That is so true. Many websites provide no age indication whatsoever... I hate guessing if the information provided was correct yesterday or five years ago.
At 00:00, for an email received one minute ago, it says "yesterday".
If they don't have space for the full date and time, it could be "Fri 23:59".
If they don't have space for the full date and time, it could be "Fri 23:59".
I mean if we are going to nitpick. Last Tuesday etc would be even better. Then past a week give the dates. If possible with day name instead of nr
I just spent a while reading several pages of the grumpy.website, lots of good content there and should be mandatory reading for UI designers
The worst part is when you share screenshot of something: there are not actually dates so person receiving screenshots has no clue.
Damn right. I don't get why but both Github and GCP don't show precise date. Why???? Who TF made the decision?
It's funny when OpenStreetMap "User blocks" page display status that "Ends in over 90 years".
Yes, I'm sick of these cutesy approximations on social media as well, it screates more confusion than clarity.
I'll go further and say anything longer ago than an hour should show the date + time, with timezone.
You don’t need time deltas for display. Just omit the prefix (left of the minute) that is equal to now.
Always use the name of the day of the week, Tomorrow is vaguetalk for Future and Yesterday, past.
Imagine in 100+ years, people watching youtube videos uploaded _1 century ago_.
Fast forward 10^8 years, and the actual date will cause too much visual clutter.
Worse date things:
* 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.
* 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.
I think we can all agree that youtube does it horribly wrong. But it seems silly to complain about a practice that increases utility by citing examples of software that has done it wrong.
And anything less than a week ago (but more than 24 hours ago) should just say the day of the week.
And anything less than a week ago (but more than 24 hours ago) should just say the day of the week.
> 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.
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.
I personally would find that quite upsetting.
I'd propose user-survey to the death at dawn at twenty paces.
Everything upload din the last 5 minutes should say the exact date.
Ca we do both, 1 year ago: 2022-1-1?
I thought about that also a week ago
I imagine the vague “a year ago”, etc is usually the product of some back end scaling strategy?
That doesn't sound like it. This is a frontend thing. The only sort of strategy I can think of is caching the page for a year, but you can cache it forever if you use an absolute date.
I fail to see how that enables any kind of meaningful scaling.
I’m definitely not an expert, but my thinking was that perhaps a “sort by new” would be much faster if there were only a handful of potential values which could be indexed, rather than every single datetime value being unique.
How about showing both?
yes please!
The obvious solution: milliseconds since 1970/1/1T00:00:00Z.
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.
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.
Url changed from https://mjtsai.com/blog/2023/10/13/relative-time-labels/, which points to this.
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.