People with technical skills can't accept that, but the ones without them that make up the majority couldn't care less. The vast majority of people don't know how to read or utilize anything past the domain name, hence why you constantly see people copy paste 300 characters long URLs of images from Google. Hell, a good amount of people don't even look at the domain name which is why phishing is so common.
URLs are not strictly technological oddities. Their closest equivalents are footnotes/citations.
Marginalizing URLs as something that only "people with technical skills" do (and/or should?) care about is no different from any other phenomenon where you take some boring, everyday, mostly unremarkable practice that doesn't involve the use of a computer and then change it where the moment someone gets a whiff of the presence of a computer in the pipeline they throw up their hands and say, "I don't know"/"I don't get this"/"I'm not a computer person".
It's really the doing of both non-technical people and technical people in and adjacent to the modern software industry alike that most people consider URLs gobbledygook instead of what they are: identifiers for a given work. It's especially perverse that the practices of both classes are responsible for most URLs being unsuitable for use Works Cited pages. That could definitely use some fixing, but we do such a poor job (in the US at least) already at explaining, during high school when it's supposed to be covered, the value of proper sourcing and citing that even smart kids come away thinking in terms of superficialities like the rigidity of formats and citation style rather than the actual fundamentals of scholarship. URLs are not exceptional in that regard.
Phones have small screens, and most browsers only show the URL on demand when you do a gesture. Also, you generally can't fit the whole URL while in landscape on a phone. You need to scroll it sideways if you want to find something in it.
I don't think we can expect URLs to be read in full by people on phones :(.
On demand is ok. But there should be an easy and convenient way to see.
> You need to scroll it sideways if you want to find something in it.
> I don't think we can expect URLs to be read in full by people on phones :(.
That's because it's implemented inconveniently, a single line.
When user taps the address bar, the browser could expand it into an URL editor, conveniently wrapping lines by url parameter boundaries, etc
Meh, everything's converged on https now, unless you're loading from file (in which case you probably know already). With any other scheme, the browser is going to pop up a massive DANGER WILL ROBINSON that you have to click through.
The scheme is rather pointless to display in a browser bar nowadays.
Having a separate scheme for HTTPS was a mistake anyway. TLS should be a transport detail that doesn't change the URL at all just like DNSSEC, IPv6 and QUIC don't change the URL. The browser can still display the negotiated encryption and you need HSTS anyway to fully protect against downgrade attacks - and as older ciphers are broken even that is not going to be enough.
People without a technical background could accept a browser that doesn't display an URL at all. Just put a nice big Button with the Google-Logo somewhere, which for many people is "The internet" and they are happy.
And anyone claiming otherwise should riddle me this: How do most non-technical people in the world access "awesomepageireallylike.something"? That's right, they click into the address bar, start typing until the string they remebered appears, and then click on that. And what is that? Exactly: A Google search.
URL is a central concept in web browsing. Hiding it from users goes against the main usability principle that the user should understand what's going on.
One does not need a technical background to understand URLs.
Browser hiding URLs is like an OS hiding file system structure from users, because files and directories are "too technioal" for them.
Sure he should. But design maxime of a lot of contemporary software does exactly the opposite: Hiding as much of the "icky techy stuff" from the user as possible.
> One does not need a technical background to understand URLs.
That's true, but doesn't change the fact that most people don't. For example, how many people know that the domain of an URL is organised right-to-left? I met people in tech, including programmers, who never figured that out.
> Browser hiding URLs is like an OS hiding file system structure from users, because files and directories are "too technioal" for them.
I agree. And now open a contemporary smart phone interface, and show me, without any special tooling, the actual, "physical" file system. And these things are probably the most successful consumer computing platforms ever.
IPs are a central concept as well but nobody advocates for making them more visible (and colorized, etc) to users.
> Hiding it from users goes against the main usability principle that the user should understand what's going on.
The main usability principle is that the user should understand what matters for them. Seeing the path of the URL is completely useless to 99% of web browsing. Better hide it by default and let power users see it if they want.
I don't think that takes like this one that yes-and URLs as a narrowly technological concern help anything. I'd argue it actually does more harm than good.
> URL is a central concept in web browsing.
Two responses, depending on one's mood:
1. So?
2. Resource identifiers—which URLs are—are a central concept to information science, scholarship, and society and culture.
Aside from the (admittedly often irrational) tendency of some non-technical people to strike a pose of helplessness,* you also end up with technical people making comments like this one: generally taking the stance that it's not too hard to pick this stuff up, with the goal that non-technical people will end up with an appreciation/conception of a URL's technological bones that at least approximately matches the informed mental model of the technical person who is speaking—and who themselves doesn't stop to consider what they themselves have got wrong and are possibly continuing to do wrong by society wrt their role in (negatively) shaping the information architecture of the world around them.
I don't like what Google's trying to do, but I don't think the address bar is good at of the roles it currently sits in (establishing trust, encoding state), and stands in the way of attempting new modes.
Why? Most urls nowadays are unreadable and nonsensical anyway. The only thing that really matters is the domain, and that’s displayed for you in a (hopefully) better way than many users would be able to parse themselves.
Of course, you should always have the option to see the full URL, but why exactly do you need that clutter on display the whole time? It’s like complaining that the browser renders HTML instead of printing it all as unformatted text.
Amen to that! It's really frustrating when a date is not put there, especially on tech topics. If no tech version is written explicitly either, you are left wondering "will this still apply to my case or is it something super-old?"
But beside selfish use-cases like looking for an answer to a problem, it is something that was already solved in the previous form of knowledge distribution: books. Why do we always take one step back when moving forward?
> But beside selfish use-cases like looking for an answer to a problem, it is something that was already solved in the previous form of knowledge distribution: books. Why do we always take one step back when moving forward?
Note that with book you have the publication date, but you don’t know when each chapter was written. This doesn’t matter for most books, but for highly technical subjects it may matter.
It's something that I agree with and increasingly I add dates in my notes. In addition to that, using one single format is really important. if the article was published on say November 2nd. I wouldn't know if it was 11th February or 2nd November. DD MMM YYYY is safest. The 3Ms being Jan, Feb, Mar....
There’s some unexpected behaviour with MMM as a formatter, which is that it’s not always 3 characters long and differ subtle by locale.
Notably on the JVM if your locale is en-GB every month is 3 chars: Jan, Feb, Mar, etc. until you get to September which is Sept.
In en-US it’s just Sep.
Of course, if you don’t specify the locale in code, it will choose the system default leading to lovely region specific exceptions for your servers in Ireland and England.
Sure it does. It's the shortest way to specify a date within a period of a year surrounding the current day... Which means it's a date format that should only ever be spoken, not committed to written record.
> 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.
I store notes in to git repository. I used to store timestamps inside the file too, but I found out I don't have the patience to add those if I change tooling like to a different markdown editor that doesn't do it automatically.
>should include a timestamp. In fact, this extends to almost anything online and even offline.
This was one of the ideas in the General Semantics philisophy. You don't much hear about it nowadays, it's a pre-war thing. One of the tenants was that you should date expressions. For example, if referring to a person, you'd write "Roosevelt, 1930" because a year later, Roosevelt may behave like a different person altogether.
Space colonization is going to be a pain. We've just managed to get sensible datetime APIs with instants and zoned timestamps, but they only work when time is the same everywhere. As soon as relativity comes into play we'll have to come up with a different approach.
All planets (in the same plane of relativity) agree on the length of a second. The length of a day varies - both on earth and on mars, and is meaningless for people in orbit, but a second is a second.
Right, the passage of time is affected by how deep in a gravity well you are (i.e. how much acceleration you are experiencing). Time passes faster for satellites than for ground stations.
Nothing in the solar system has a relative speed different enough to earth to make common timestamps different - the difference is well below leap second impacts.
As for simultaneity we already have to deal with that at the millisecond level. An event logged at 16:00:01.000 as far as LA is concerned maybe logged at 16:00:01.080 in London, or maybe at 16:00:00.920
I mean the clocks on different planets do tick at slightly rates. It's somewhere on the order of milliseconds per year, except for really large planets, but it does add up
Space travel will be relatively easy since requires computers. Everyone will keep track of their local clock in seconds. Then they will calculate clock for places they care about, eg Earth-time, since those are pretty predictable. Relativistic corrections will be pretty minor.
My guess is that planets will keep local day-year. Mars is close enough to Earth that throwing in extra 37 min might make sense. OTOH, most planets and moon might use Earth calendar because local day cycle is too far off human internal clocks.
They will calculate time for other places, but will be less important than time zones since every communication will have light speed lag. No video calls, but lots of email.
That's called time-binding, and it actually predates Korzybski's coining "general semantics" in the 1930s. He wrote about it in his first book Manhood of Humanity, which is public domain[2].
I ran into a fun bug last week. I wrote a piece of .Net Core software that accepts a batch of transactions. The transactions are shovelled into Sql Server without much processing. Each transaction had a timestamp set to DateTime.UtcNow in C#. I didn't expect the transactions to end up with duplicate timestamps but DateTime.UtcNow only has a resolution of between 0.5 and 15 milliseconds. So in a tight loop I got duplicates and couldn't determine the order my transactions were processed when querying the db, which is important!
In the end I used Sql Server's SYSUTCDATETIME which is precise to 100 nanoseconds. More importantly I gave all transactions in the batch the same timestamp, added a batch order int column, and a unique contraint on the timestamp, batchOrder columns.
Turns out DateTime.UtcNow is not really designed to give you a precise value for a messaging or transaction system! More of a sometime that day, probably.
Edit: don't trust timestamps, especially from different sources.
Timestamps no matter how precise don't show you the true order. If ordinality is so important then you should be using something else that guarantees ordinality, like an incrementing ID or something, not timestamps.
Not everything is written at a given point in time and then forgotten about. There are many texts that are continuously updated over years and even decades.
That's a good thing, because that final edit is a discrete event. At some point this ongoing process will end and the edits will stop. The people engaged in the process will likely forget or not be available to add a final timestamp, but an aging edit timestamp will automatically indicate this moment in time.
Which timestamp is relevant on the body of a Wikipedia article that has been maintained for 15 years, with edits ranging from entire new sections being written to minor corrections of grammatical errors.
I’ve found that internal documentation is a great place to put timestamps. People often complain that eg architecture pictures or design documents tend to go out of date, as if that’s somehow a big enough problem to not make them.
Instead, consider making whatever documentation seems useful at a given moment and timestamp it with a clear, prominent “this was accurate on yyyy-mm-dd”. It will still be useful a year later, because people are actually very good at dealing with “ok this detail might have changed since then so I’m not going to let that confuse me when mapping the doc/diagram to the code” kind of stuff.
When things have diverged too much, just make a new one. And timestamp it!
Addendum: don’t rely on your git/wiki/document-system for tracking the timestamp. “This was accurate on $DATE” has a very different meaning than “this document was last edited on $DATE”. It might be 2 years out of date but someone fixed a typo last week.
Just put a sentence/textbox somewhere with the date. If someone does a proper update, they will proudly edit that sentence too.
> It might be 2 years out of date but someone fixed a typo last week
Or it might have had a fuller update last week, but from older information (perhaps going from years old to months old) because it is information that has a high processing latency (like census data). Though in this case the date probably belongs in the text with the timestamp representing the edit date, either way both times should be made clear.
I've found that keeping a changelog as part of my design docs and similar is a good way to keep engineers, even across teams, confident that what they are looking at is up to date and a good reference, and the right document to update if necessary.
I can only endorse this, but would like to add that I always put my name and email address and a version number on top of the document. The additional version number is useful for keeping track of changes. Often I indicate what changed since the last version of the documentation or I have a separate HISTORY.txt file in the documentation folder including all versions, dates an a brief comment, what has changed.
If a question comes up later, I can first ask the questioner which date or version of the documentation they are relying on. More than once, the problem has been solved simply by sending the person the current documentation again.
Documentation maintenance seems underrated. For most of my career, information was dumped in a wiki, so that everyone could maintain it. But if everyone maintains it, nobody does.
Every project needs someone responsible for someone taking ownership of the documentation, including research and timestamping and the like. Have a todo list where the oldest document goes on top, check it for relevance and accuracy, cull it if it's outdated, get it up to date otherwise, and (as this comment recommends) update the timestamp.
My current project has a wiki going back years, loads of duplicate information, no clues whatsoever if it's still relevant.
Of course using a timestamp can also cause troubles.
Newsmax reported that PBS knew about the assault on the capitol before it even happened because they put a timestamp on their web page for the Trump congregation when they first published it early in the morning.
They then proceeded to update the page without updating the timestamp, making it look like they predicted the invasion hours in advance
I already start to visualize the new crawler service that will put a date on articles that first appear on the web. Since everyone suck up to the seo demon. Yes, I want to be the first, yes, look how shiny I am and I was published right now, not 3 years back. Instead of making a new feature:
hello, I'm the shiny new search, and what I offer is that whenever I have found 250 articles that perfectly solve your problem for a search term, I round robin these on the "first page" and you decide which one to choose from the offered ones. This way everyone has an equal opportunity to get some views plus nobody has to do these mating dances to get on the front page.
That wouldn't be considered a timestamp in my book. For starters, it doesn't have time information, only date information. Quickly asking ChatGPT it gives this answer:
In computing, timestamps are commonly expressed in formats like "YYYY-MM-DD HH:mm:ss" (year-month-day hour:minute:second).
When pressed about this particular time detail, ChatGPT elaborates:
While "YYYY-MM-DD" is a common date format, it's not complete for a timestamp, which typically includes both date and time information. A complete timestamp might look like "YYYY-MM-DD HH:mm:ss" to include hours, minutes, and seconds.
So, no, this post doesn't contain a timestamp, and it already fails in its own advice.
The blog post contains a timestamp in the RSS feed. In fact, the referenced post by Julia Evans also contains a timestamp in its RSS feed as well.
However, the post is making the point that the date should be in the post as viewed by the human reader as clearly as possible, which isn't the case in the the referenced post by Julia Evans.
In the third paragraph the author notes that "Only when I copied the URL to complain about it I discovered the date there". So there is no confusion on the author's part about what a timestamp is versus what a date is.
Quite the nitpick. They obviously mean date not timestamp.
The fidelity increase of Date->Timestamp for a blog post is almost nothing (unless you are reporting on current events, e.g. the BBC has timestamps in their live reports).
The fidelity increase of {} -> Date is much higher. For tech you now know that this article is likely incorrect. E.g. if it is 10 years old and about how to install Node or something.
I always use timestamps. Not just on blog posts, but on files, notes and sketches.
For public stuff, dates help others judge whether the information still applies. This matters for most types of information, but particularly technical advice. I write about German bureaucracy and a lot of the information from a few years ago is outdated.
For private stuff, dates gice you a sense of time. A good example is if you've been writing about a weird lump on your neck hurting for over 4 weeks, or realise that you were stressing about the same things a year ago. Sometimes it's just nice to see "on this day" trivia about yourself.
That’s ambitious, but entirely unrealistic in many cases.
For one thing, people do screenshot/download/archive web sites; these copies don’t get updated, and it can be important to know when they were last updated (as opposed to when the snapshot was created by a third party).
In that case he should put a "last updated" on each posts. Plus that would offer even more incentive to keep things up to date, since you're giving yourself a public "mark of shame" if you don't
It's extremely annoying because his posts get reposted to social media a lot and you suddenly have to go on a treasure hunt to figure out if he's revisiting old topics, or you read it five years ago.
Yes. Yes. Yes. A million times, yes. I can't stress this enough: always put visible timestamps on all content (be it web or otherwise, online or offline) and current version number for any kind of software (apps, libraries, frameworks, etc.) on their info / landing / documentation pages.
It should be immediately visible if a certain content is dated or not.
A <time> and <datetime> element exists in HTML, but why don't an element exists that will format a date and time written in a specific format to the format of what the user want? I'm talking about automatic TZ conversion.
For example, sometimes I mostly care about when, in relation to my local time (and in particular how long ago) something was written; other times, the local time of the event happening is relevant too (e.g. “did this happen before or after markets close in the country where it happened”).
It's been a while since I did any frontend work, but I recall that the Date Javascript object does do that. I was able to just send a UTC timestamp from the backend, then do something like (I've not tested this right now)
new Date(timestampMs).toLocaleString()
and it just worked. Correct timezone and locale. Not sure why that simple approach isn't more widely used
Few things irk me as much as systems that show you "N hours/minutes/seconds ago" instead of the timestamp. GitHub for example, of all systems, should know better. Trying to write up a report of any sort and not having access to accurate timestamps is very annoying.
I haven’t checked github, but on gitlab this is a user preference setting that you can change. But I do wish that the full timestamps were the default.
Yep, my theory is that often that's done as a way to sidestep difficult issues around dealing with time zones. "2 hours ago" doesn't require you to think about whether your user is in the same time zone as your database.
Your server and DB are both UTC. If not, that's something you just need to fix. The server can then calculate the difference trivially. Then you no longer need to do anything on the client. Eg, this is what Django's timesince or timeuntil filters do: https://docs.djangoproject.com/en/4.2/ref/templates/builtins...
162 comments
[ 3.2 ms ] story [ 231 ms ] threadMarginalizing URLs as something that only "people with technical skills" do (and/or should?) care about is no different from any other phenomenon where you take some boring, everyday, mostly unremarkable practice that doesn't involve the use of a computer and then change it where the moment someone gets a whiff of the presence of a computer in the pipeline they throw up their hands and say, "I don't know"/"I don't get this"/"I'm not a computer person".
It's really the doing of both non-technical people and technical people in and adjacent to the modern software industry alike that most people consider URLs gobbledygook instead of what they are: identifiers for a given work. It's especially perverse that the practices of both classes are responsible for most URLs being unsuitable for use Works Cited pages. That could definitely use some fixing, but we do such a poor job (in the US at least) already at explaining, during high school when it's supposed to be covered, the value of proper sourcing and citing that even smart kids come away thinking in terms of superficialities like the rigidity of formats and citation style rather than the actual fundamentals of scholarship. URLs are not exceptional in that regard.
I don't think we can expect URLs to be read in full by people on phones :(.
> You need to scroll it sideways if you want to find something in it.
> I don't think we can expect URLs to be read in full by people on phones :(.
That's because it's implemented inconveniently, a single line. When user taps the address bar, the browser could expand it into an URL editor, conveniently wrapping lines by url parameter boundaries, etc
(A scream goes out)Function before form, always!
The scheme is rather pointless to display in a browser bar nowadays.
And anyone claiming otherwise should riddle me this: How do most non-technical people in the world access "awesomepageireallylike.something"? That's right, they click into the address bar, start typing until the string they remebered appears, and then click on that. And what is that? Exactly: A Google search.
One does not need a technical background to understand URLs.
Browser hiding URLs is like an OS hiding file system structure from users, because files and directories are "too technioal" for them.
Sure he should. But design maxime of a lot of contemporary software does exactly the opposite: Hiding as much of the "icky techy stuff" from the user as possible.
> One does not need a technical background to understand URLs.
That's true, but doesn't change the fact that most people don't. For example, how many people know that the domain of an URL is organised right-to-left? I met people in tech, including programmers, who never figured that out.
> Browser hiding URLs is like an OS hiding file system structure from users, because files and directories are "too technioal" for them.
I agree. And now open a contemporary smart phone interface, and show me, without any special tooling, the actual, "physical" file system. And these things are probably the most successful consumer computing platforms ever.
Yes, I had phones in mind when writting the above :)
> And these things are probably the most successful consumer computing platforms ever.
Users don't have better choice in this market.
What I am certain of, is that it's very inconvenient to not have access to file systems.
Yes, well, this is how mobile OSs behave and most people don't seem to care or even notice...
> Hiding it from users goes against the main usability principle that the user should understand what's going on.
The main usability principle is that the user should understand what matters for them. Seeing the path of the URL is completely useless to 99% of web browsing. Better hide it by default and let power users see it if they want.
> URL is a central concept in web browsing.
Two responses, depending on one's mood:
1. So?
2. Resource identifiers—which URLs are—are a central concept to information science, scholarship, and society and culture.
Aside from the (admittedly often irrational) tendency of some non-technical people to strike a pose of helplessness,* you also end up with technical people making comments like this one: generally taking the stance that it's not too hard to pick this stuff up, with the goal that non-technical people will end up with an appreciation/conception of a URL's technological bones that at least approximately matches the informed mental model of the technical person who is speaking—and who themselves doesn't stop to consider what they themselves have got wrong and are possibly continuing to do wrong by society wrt their role in (negatively) shaping the information architecture of the world around them.
* See <https://news.ycombinator.com/item?id=38277553>
Without a URL, you can't text someone a webpage, refer to it in a social media post or a tweet, or link to it in a document. You can't make links.
Sure, you can browse the web without it. But you can't use any of our everyday basic tools for sharing and content creation without it.
Of course, you should always have the option to see the full URL, but why exactly do you need that clutter on display the whole time? It’s like complaining that the browser renders HTML instead of printing it all as unformatted text.
But seriously, what are you trying to say, that we need to make software match our contemporary physical experience? No, we can do better.
But beside selfish use-cases like looking for an answer to a problem, it is something that was already solved in the previous form of knowledge distribution: books. Why do we always take one step back when moving forward?
Note that with book you have the publication date, but you don’t know when each chapter was written. This doesn’t matter for most books, but for highly technical subjects it may matter.
Notably on the JVM if your locale is en-GB every month is 3 chars: Jan, Feb, Mar, etc. until you get to September which is Sept.
In en-US it’s just Sep.
Of course, if you don’t specify the locale in code, it will choose the system default leading to lovely region specific exceptions for your servers in Ireland and England.
The most nonsensical approach is what the Americans use but let's not go there : - )
https://en.m.wikipedia.org/wiki/ISO_8601
Starting with the day or the month is Ludacris.
And if you are using something else, especially if it’s something like XX-XX-XX, specify what you mean by that!
> 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.
E.g. French has Juin and Juillet, both "jui" start.
Better to just use yyyy-mm-dd everywhere. I see so many bugs from people still using US date format in 2023.
This was one of the ideas in the General Semantics philisophy. You don't much hear about it nowadays, it's a pre-war thing. One of the tenants was that you should date expressions. For example, if referring to a person, you'd write "Roosevelt, 1930" because a year later, Roosevelt may behave like a different person altogether.
As for simultaneity we already have to deal with that at the millisecond level. An event logged at 16:00:01.000 as far as LA is concerned maybe logged at 16:00:01.080 in London, or maybe at 16:00:00.920
The difference is negligible compared to leap seconds.
My guess is that planets will keep local day-year. Mars is close enough to Earth that throwing in extra 37 min might make sense. OTOH, most planets and moon might use Earth calendar because local day cycle is too far off human internal clocks.
They will calculate time for other places, but will be less important than time zones since every communication will have light speed lag. No video calls, but lots of email.
1. <https://en.wikipedia.org/wiki/Time_binding>
2. <https://openlibrary.org/works/OL168124W/Manhood_of_humanity?...>
Probably a lot fewer than you'd think. And certainly not every article you write.
In the end I used Sql Server's SYSUTCDATETIME which is precise to 100 nanoseconds. More importantly I gave all transactions in the batch the same timestamp, added a batch order int column, and a unique contraint on the timestamp, batchOrder columns.
Turns out DateTime.UtcNow is not really designed to give you a precise value for a messaging or transaction system! More of a sometime that day, probably.
Edit: don't trust timestamps, especially from different sources.
At the very least you should provide the inital publish date and last update.
What other modern browser does this? Tested both Firefox and Chromium and neither did.
Instead, consider making whatever documentation seems useful at a given moment and timestamp it with a clear, prominent “this was accurate on yyyy-mm-dd”. It will still be useful a year later, because people are actually very good at dealing with “ok this detail might have changed since then so I’m not going to let that confuse me when mapping the doc/diagram to the code” kind of stuff.
When things have diverged too much, just make a new one. And timestamp it!
Just put a sentence/textbox somewhere with the date. If someone does a proper update, they will proudly edit that sentence too.
Or it might have had a fuller update last week, but from older information (perhaps going from years old to months old) because it is information that has a high processing latency (like census data). Though in this case the date probably belongs in the text with the timestamp representing the edit date, either way both times should be made clear.
I use this one that allows you to configure the output format:
https://marketplace.visualstudio.com/items?itemName=gieson.w...
If a question comes up later, I can first ask the questioner which date or version of the documentation they are relying on. More than once, the problem has been solved simply by sending the person the current documentation again.
Every project needs someone responsible for someone taking ownership of the documentation, including research and timestamping and the like. Have a todo list where the oldest document goes on top, check it for relevance and accuracy, cull it if it's outdated, get it up to date otherwise, and (as this comment recommends) update the timestamp.
My current project has a wiki going back years, loads of duplicate information, no clues whatsoever if it's still relevant.
Newsmax reported that PBS knew about the assault on the capitol before it even happened because they put a timestamp on their web page for the Trump congregation when they first published it early in the morning.
They then proceeded to update the page without updating the timestamp, making it look like they predicted the invasion hours in advance
hello, I'm the shiny new search, and what I offer is that whenever I have found 250 articles that perfectly solve your problem for a search term, I round robin these on the "first page" and you decide which one to choose from the offered ones. This way everyone has an equal opportunity to get some views plus nobody has to do these mating dances to get on the front page.
What a brave new world!
When pressed about this particular time detail, ChatGPT elaborates: While "YYYY-MM-DD" is a common date format, it's not complete for a timestamp, which typically includes both date and time information. A complete timestamp might look like "YYYY-MM-DD HH:mm:ss" to include hours, minutes, and seconds.
So, no, this post doesn't contain a timestamp, and it already fails in its own advice.
However, the post is making the point that the date should be in the post as viewed by the human reader as clearly as possible, which isn't the case in the the referenced post by Julia Evans.
In the third paragraph the author notes that "Only when I copied the URL to complain about it I discovered the date there". So there is no confusion on the author's part about what a timestamp is versus what a date is.
> Also, don't make me look for the date. Put the date as obvious as possible, preferably at the beginning of the post.
The fidelity increase of Date->Timestamp for a blog post is almost nothing (unless you are reporting on current events, e.g. the BBC has timestamps in their live reports).
The fidelity increase of {} -> Date is much higher. For tech you now know that this article is likely incorrect. E.g. if it is 10 years old and about how to install Node or something.
For public stuff, dates help others judge whether the information still applies. This matters for most types of information, but particularly technical advice. I write about German bureaucracy and a lot of the information from a few years ago is outdated.
For private stuff, dates gice you a sense of time. A good example is if you've been writing about a weird lump on your neck hurting for over 4 weeks, or realise that you were stressing about the same things a year ago. Sometimes it's just nice to see "on this day" trivia about yourself.
If you have the date, you can correlate data from different sources onto a single timeline. I made a nice project out of that: https://nicolasbouliane.com/projects/timeline
https://danluu.com/cpu-bugs/
There is date on the index page Jan - 2016, however it's not obvious from the content page.
I think the argument is that the content should be corrected if it's outdated. So, it shouldn't matter when it was written.
For one thing, people do screenshot/download/archive web sites; these copies don’t get updated, and it can be important to know when they were last updated (as opposed to when the snapshot was created by a third party).
Some examples of software-related landing pages:
https://sindresorhus.com/caprine/ (Caprine app) - shows current version number
https://riot.js.org/ (Riot.js framework) - shows NPM badge with latest version number
... it's not so hard now, is it?
For example, sometimes I mostly care about when, in relation to my local time (and in particular how long ago) something was written; other times, the local time of the event happening is relevant too (e.g. “did this happen before or after markets close in the country where it happened”).
It's usually possible to hover the thing to have the actual timestamp show in a tooltip, but this is so clunky.
Previously discussed at https://news.ycombinator.com/item?id=33446662