> just give me ISO8601 dates, please; HackerNews, you, too!

Strongly seconding. It's an annoying UX antipattern, especially as it loses precision over time ("28 minutes ago" is fine, but "yesterday" or "5 days ago" or - even worse - "2 years ago" is not; having the date specified to hours or minutes is actually useful, especially in context of a site with international audience). Doubly so on HN, which doesn't even bother with giving the actual date/time in the tooltip, which is the usual cop out (not an actual solution, since there are no tooltips on mobile).

Definitely agree about the loss of precision. It's also a problem for machine readability and SEO. The solution I like is using the HMTL5 <time> element for semantic markup of timestamps. If you do something like this:

    <time datetime="2019-10-11T13:53:36.861" title="Fri Oct 11 2019 13:53:36 GMT-0700">2 minutes ago</time>

Then you get what in my opinion is the best of both worlds: machine readable timestamp in the datetime field, human-friendly detailed timestamp as a tooltip (the title field shows when you hover over the element), and relative time as the default display. Bonus points if your React component or ERB template or whatever switches from relative time format to absolute for the inner text when the timestamp is older than a day or so.

"when you hover over the element"

On the website I'm looking at Google Analytics for right now, fewer than 35% of the visitors are from devices where "hover" means anything...

Well, it would require JS, but you could turn it into a button to show/hide an HTML tooltip or additional displays of the time. That iOS supports a mouse (in accessibility settings) or an Xbox controller but doesn’t properly support an “abbr” tag... it was acceptable in 2007 when we were happy to see the phone load nytimes.com with all its columns. It’s feeling very out of date in 2019, when 12 years later we’re adding downloads and “desktop safari” but we never finished the “desktop-equivalency” parts of the HTML5 spec. It would be amazing if Apple ported some of their iOS native components to web components or to enhance HTML5 elements. The farthest we’ve gotten so far are keyboard search button hints, if I recall correctly. Which is really quite disappointing, that an app made for jQuery UI would work as well as an app from today if you flatten and modernize the design, and add a bit of offline caching...

I prefer the HN method of 28 min, yesterday, 2 hours ago, etc... for HN. The older a comment or post, the less relevant it is to a particular discussion. This site is for real-time discussions of articles, so it is optimized for that use-case. The older a comment, the less relevant it is towards the immediate discussion. Thus, older comments have less precision, because those details don't matter for the discussion.

I'd expect a site/application that is designed for students to manage homework would have different date/timestamp requirements.

HN may be optimized for current discusions, but is also a repository of knowledge; I frequently land on years old threads from Google searches. For older times, an explicit ISO timestamp has at least two benefits: 1) I can compare it easily to other dates (e.g. is that comment older or more recent that event X, or software version Y), and 2) time of the day is a half-decent proxy for telling whether the US or Europe was awake then.

And while you can justify the inprecise stamp on HN, there's no excuse for GMail and a score of other messaging software doing the same. When I'm looking at the date of an old e-mail, I almost always need the exact date and time. "2 weeks ago" is useless. "2019-09-27 08:43" tells me it happened before work, on a day after an important meeting, etc.

ISO8601 date/time can easily be transformed into the fuzzy format HN uses, but not vice versa since the fuzzy format is lossy.

If HN sent dates to the client in ISO8601, the client could then transform that format into the format of their choosing with client-side javascript (either a userscript, or delivered to the user by HN.)

It's hard to be sure this isn't satire.

You mentioned 'for HN' twice in the same sentence.

Your 2nd, 4th, and 5th sentence all try to assert the same thing - older comments are less relevant than newer comments - despite there being no evidence, anywhere, that this is the case. Your 3rd sentence is partly true, though there's some historical record aspect to HN comment threads that you're discounting.

Your second paragraph is a non sequitur. Sites that correlate points in time with timestamps are ubiquitous, and there's rarely a compelling case for using wildly different approaches to displaying same.

They could easily do it the Reddit way and still provide a timestamp but keep the simplicity and relative time format. Just have it pop up the timestamp on mouse hover. That's still very simple and can be effectively done using just CSS.

You don't even need any CSS for that — the title attribute alone would be sufficient.

Personally I like HN the way it is. Very little UI clutter. If we start doing ISO dates and maybe options to switch between high precision and default low precision, we lose the good feel that HN has produced.

I'd prefer both.

I have one word to tell you: timezone

What about them? ISO8601 supports time zones.

> The problem is people design these things without any sort of actual testing in actual conditions where the software is supposed to be used.

I’ll do YOU one better. </Drax>

I work in an industry where software is still created by good, old-fashioned, by-the-book waterfall process, by outsourced developers. You know: the industry-proven, rock-solid, 20-year-out-of-date, slowest-and-least-agile methodology. Not only do the people who write the software never use it anger, they have no clue what the software is supposed to actually be doing. They don't understand our product, don't understand HOW these KINDS of products work, don't understand what engineers are doing TO the products, and don't understand what would be useful to have from software to help DO that. How many steps removed from actually USING the software is that? Well, you can imagine the frustration that end users experience on a DAILY basis, with ALL the tools they're supposed to be using, both home-grown, and customized commercial.

Gee… I wonder why there are so many shared Excel workbooks functioning as ad-hoc database applications on the network drives…

The most damning part of this is that there were some studies done on our engineering processes in relation to our competitors, and the numbers were bad. Really bad. You would think that senior management would sit up, take notice, and connect the dots. But they don’t seem to be doing that, which leads to one of two conclusions, and neither are encouraging.

Sounds god awful. What industry do you work in?

I find it hard to understand how a business like this stays alive. Really, how?

I'd disagree a little, the problem is not testing, it's building the software in the first place when it doesn't solve a real problem.

This so much.

Sadly, what you describe as the anti-pattern is actually the industry standard.

And you don't have to go far to see examples — Slashdot and Reddit redesign come to mind. Both are unusable.

> Having restrictions on filetypes is a bug, not a feature.

It should be - but for many school IT security types it really is a feature to limit file types

I fought this during my entire teaching career.

Blocking file types by extension is pointless. as you can just change the file type.

If you're worried about kids being able to run arbitrary python scripts on your network, then the security problem is not the kids, it's your shitty network.

People are given cash as bug bounties for finding security flaws in systems, but in schools they are punished!

>If you're worried about kids being able to run arbitrary python scripts on your network, then the security problem is not the kids, it's your shitty network.

How is this even possible? Unless your CMS runs on python somewhere and does eval() a lot. Then yes, that is a huge problem. Moreover, why would that stop anything just not called .\+\.py?

If your CMS does `python ${fileIjustdownloadedfromuser}` in a shell then we are in serious trouble.

I think it's also a problem when people are rewarded for finding these kinds of bugs that are not actual bugs.

Some bad person vandalised an obscure public Oracle repository on GitHub that's not even for any public product they're known for (OpenGrok). Instead of being banned, the owners restricted public edits. WTF? It's small things like this that end up being having the anti-pattern become the norm.

Could not agree more!!!

What about security patterns for web browsing?

I feel the logic is somewhat similar but injections to websites / applications may be easier and hard to prevent against, so filtering pornography may be useful. I’m a dev not a security expert so sorry in the lack of understanding. I am actually trying to learn more about security / hacking

Security: it seems to me that in the wild, 40% of it is security theater, another 40% exists primarily to ruin your mood and control you the user, and remaining 20% is actually around the right trade-off between utility and safety.

I agree that it is mostly theatre. I understand not allowing an exe, but if you have to download the file and rename it, how much of that would be unintentional?

This reminds me how for awhile I was emailing myself .tar and .exe files through Gmail or school email systems by renaming them to .jpeg files.

Recent-ish (past year) Gmail patched this (for .tar at least), so I started using base64 encoded text files.

Now though I just pay for my own email service away from Google.

O365 blocks ps1 files by default. ps1 files aren't executable by default on any windows machine.

why is the vendor that makes the OS (MS) making these types of decisions?

Agreed, but trusting the extension at the end of the filename for this purpose screams, "amateur hour."

Extensions were important to filter when Windows explorer was still lacking rules to forbid file execution based on provenance, but was already defaulting to a) hide the file extension and b) display whatever pixels were embedded in an executable as the file icon. The combination of a) and b) was making even moderately security aware users utterly defenseless.

HN? Let Oracle and SQL Server databases start using that without one forcing them to. There's a long list of stuff to be bothered with before even looking at HN.