This would be a valid argument for not persisting dates as relative values.
It isn't an valid argument against presenting dates this way.
The OP's POV seems, to my eye, driven by the fact that primitive screen-scrapers can't just run a simple "toDate" function to provide it, API style, to some back-end. But it doesn't mean that it's not possible to convert them - it's not even that hard.
Fortunately, UI designers care more about their actual users than satisfying 3rd party leeches.
a) Who cares about screenshots? "I'm going to the pub on Thursday" suffers from exactly the same issue.
b) Nonsense. Of course relative dates are machine readable. But anyway, web rendering != API.
c) These examples are not ambiguous, they are merely less precise
And less precision is, indeed, often what a user wants. That's why we don't print "posted 124568080nanoseconds ago". Simplifying to a reasonable unit, appropriate to the application, reduces cognitive load on the user. Most people struggle to tell you today's date, let alone knowing how long ago an arbitary timestamp was.
I like twitter (who maintain a relative date on the top-right of the feed entry) and gmail exactly the way they are.
I had a similar idea about 10 years ago, but never got around to implementing it.
I'm amazed at the amount of hatred directed towards this - as if the terminal could in NO WAY be improved?!. But clearly it can. For example - wouldn't it be nice to have a terminal status bar with your CWD / git branch / etc in, without cluttering up space before $? Yep, you can use screen, and that destroys your ability to use the scrollbars.
Or, consider filename completion. Wouldn't it be nice to show the intended completions in a popup as you're typing (like web browsers do) ?
Why, when I do 'ls', can I not drag & drop one of the files to another finder window? Why is the terminal forever isolated?
Why when I run 'mvn install', which generates umpteen bazillion lines of output, can the result not be folded into a single line showing the summary, that I could expand if I wished?
There's lots of scope for this kind of thing. My main concern would be whether a single WebKit control is the right way to go - it'd be nice to, for example, embed custom controls within the shell (but this might also be possible).
The trademark issue meant that it didn't matter what the community wanted, it could be 1,000,000 : 1 against, if the 1 was Oracle, they could stop (or force) anything they wanted.
Commercial interests had wanted to move to Eclipse before. Most developers see the Eclipse process as overly bureaucratic and unfriendly - and therefore were -1 on that.
The whole process has been an attempt to try to force-feed the development community into eclipse, whether they like it or not. Because they hold the trademark, they have the control.
Well, thing is, eclipse was disliked before, and it is disliked now. I seriously doubt any devs will be considering it.
It isn't an valid argument against presenting dates this way.
The OP's POV seems, to my eye, driven by the fact that primitive screen-scrapers can't just run a simple "toDate" function to provide it, API style, to some back-end. But it doesn't mean that it's not possible to convert them - it's not even that hard.
Fortunately, UI designers care more about their actual users than satisfying 3rd party leeches.