Get the top HN stories in your inbox every day.
djaro
jjav
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!
HeavyStorm
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.
krater23
I feel like they regulary do this contests and are only working in making UI more shitty every day.
aristus
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.
Cockbrand
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
jjav
> IIRC this started in the Mac finder with OSX 10.2.
I see proper timestamps in Finder in Date Modified column.
troupo
IIRC the trend started with Twitter
handsclean
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).
bbx
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".
wlesieutre
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.
o11c
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.
Zambyte
I found myself using an official YouTube client by accident recently, and it was so jarring to not be able to easily see when the video I was watching was uploaded.
nfriedly
It looks like there isn't a revanced patch for that yet, but I bet there will be soon.
1vuio0pswjnm7
"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.
funcDropShadow
> 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.
BD103
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.
fifticon
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..
roelschroeven
> 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.
johnnyanmac
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.
eashman
However, on mobile iOS Safari there’s no standard way to trigger a tooltip that I’m aware of.
glaucon
>The crayon eating has gotten out of hand
Beautifully put.
antonvs
> ARE YOU PEOPLE OUT OF YOUR BLOODY MIND?
No, they’re just stupid, or at best, ignorant to a degree that makes them incompetent.
troupo
> 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...
not_your_vase
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.
xp84
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.
Moru
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.
xjay
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...
Analemma_
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.
dreamcompiler
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!".
arter4
>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.
philistine
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.
pphysch
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.
finite_depth
[dead]
afavour
> 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.
corbezzoli
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.
BrandoElFollito
> 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.
Terr_
> When did you have such a web?
When I was using The Proxomitron to rewrite incoming HTML on the fly. :p
titzer
It's really been downhill since the BBS.
midasuni
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.
marcosdumay
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.
kevincox
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)
Izkata
Likewise on Firefox, doesn't seem to do anything despite the compatibility table saying it does.
makeitdouble
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.
john_cogs
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...
simon04
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.
gsich
>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.
Am4TIfIsER0ppos
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.
finite_depth
[dead]
gsich
For some insane (=AM/PM) reason the language is tied to time preference.
o11c
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.
Too
I found that setting language to UK instead of US avoids a lot of the goofiness like YY/DD/MM and 12h time. Setting the language to my native tongue instead of English just doesn’t work for all the industrial terms.
thebigspacefuck
Thank you for supporting this. Anyone know if GitHub has a similar option?
troupo
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?!
pavel_lishin
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.
crtasm
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
pavel_lishin
Ooh, I'll see if I can do that this week.
jbaber
I think I'm at 8 different greasemonkey scripts to manhandle Jira.
zoky
> 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.
djha-skin
Date calculations are really easy for most people. Even in this case I just think I would be annoyed.
Izkata
> 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
makeitdouble
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.
pmontra
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.
mpweiher
> ... screenshot ...
And screenshots are, IMHO, one important reason it should always be the full date.
drpixie
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.
jquast
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...
MaxBarraclough
I'm surprised that there seems to be no way to configure gitg to always show full datetimes.
ranting-moth
Wow, what the screenshot is showing is a candidate for a professional misconduct if we had a governing body.
jacknews
Just have both:
- An hour ago (15:47)
- Last week (MON 12 SEP 9:20)
- Two years ago (WED 14 APR 2021 11:47)
dijksterhuis
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.
hn_throwaway_99
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.
mjl-
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.
myk9001
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.
haliskerbas
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.
layer8
That’s true, though arguably it would be possible (and useful) to add copy-ability to tooltips (by context menu for example).
michaelcampbell
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.
opan
Long-press, usually, which kind of conflicts with right click at the same time...
jacknews
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 ;)
watwut
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.
mvdtnz
Just use the date. Enough of this nonsense.
lhamil64
What about on mobile?
yreg
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.
kirubakaran
Long press brings up tooltips in iOS. Perhaps in Android too.
dijksterhuis
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.
ccooffee
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.
mjl-
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.
yosito
Approximately two thirds of my time on the internet is spent without a mouse, so probably not.
coding123
You need to tooltip it without underlines... Maybe you did but couldn't tell from your comment.
ccooffee
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.)
mvdtnz
Why? What's wrong with just the date?
jameshart
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
2023/10/09 13:47:20 (Monday, 5 days ago)john_cogs
You can set your preference to display exact times in GitLab. See my prior comment: https://news.ycombinator.com/item?id=37881456
bombcar
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.
mvdtnz
Obviously when I said "just the date" I mean the full date time stamp, which is the thing we're discussing.
pridkett
In my mind 2020 was still last year. Having both relative and absolute is a nice reminder.
bombcar
But I really don't need to see 2000 (Twenty three years ago).
tome
It significantly reduces mental exertion to have the calculation performed for you!
pintxo
The problem with this is that the dev cannot know which calculation I need!
myk9001
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.
mvdtnz
"Significantly"? Are you sure?
doomroot
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.
mvdtnz
Seriously? Your complaint is that you have the extra mental overhead of having to know the time?
0fox
The main complaint in this thread seems to be that the chunks of time reported are misleading.
dotnet00
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).
sevrinsky
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.
watwut
I have current time constantly on the right bottom portion of the screen. I do know the time literally any time I want to.
loloquwowndueo
There’s this wonderful thing called a “watch”…
xigoi
I don't usually remember what date it is.
kube-system
Sometimes relative time is more user friendly or more accurately answers a question.
SpaceNoodled
Sometimes I turn my math brain off
jrmg
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.
bxparks
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
jiveturkey
not sure what the confusing part is here? 02 = 2002.
kevincox
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.
yibg
Is it Aug 11 2002 or Nov 8 2003 or Nov 2 2008?
Aspos
"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"
fatih-erikli
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.
dreamcompiler
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.
survirtual
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.
poorlyknit
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"
jstanley
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"?
delusional
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.
kube-system
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.
hrnnnnnn
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?
Too
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.
hrnnnnnn
Ah, good to know. I'm still learning the language and haven't gotten much into detail with talking about time.
undefined
croes
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.
olddustytrail
I think they meant "more than 24 hours" rather than "less". It makes more sense in context.
tomjakubowski
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
olddustytrail
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.
thfuran
I think you switched around your sixes and nines.
SpaceNoodled
Anything in the next 24 hours, obviously.
Get the top HN stories in your inbox every day.
Especially because it becomes so imprecise. On YouTube, "1 year ago" can mean anywhere from 365 to 729 days. Anything between 1 and 2 years ago becomes "1 year ago".
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.