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.
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.
> 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.
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.
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.
>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.
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].
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.
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.
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.
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...
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.
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.
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.
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.
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.
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
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.
When I was doing research, I was bothered by the date not being anywhere in papers (PDFs).
You'd have to search the title of the paper with the names of the authors on the internet, figure out which version you are reading and find out the year of the publication using dblp [1] or finding out in which journal or conference it was published.
Yet, it's so important to actually know when something was written.
I don't know of any paper template that includes the date. Usually it is only found if the preprint paper adds it (like arxiv) or in the copyright notice, that not all papers include.
With topics like ML and NLP that move fast, even the day/month becomes important, not just the year.
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....
> 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.
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.
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.
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.
But the whole point of people/companies not putting timestamps on articles and posts is precisely to hide how very old their content is, because they are (rightly) afraid people will click away.
It's not laziness or ignorance, it's generally intentional. So it's not like this advice is going to change their minds.
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.
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.
Give context in titles. (The post is a size of a tweet about using them on publications.) Don't make me click to see if I might be interested in opening this content.
Dropping timestamps is very akin to using terse catchy titles, it draws in the unsuspecting and gives content wider/longer exposure.
Normally I would agree with you, but the "In fact, this extends to almost anything online and even offline." is implied by the generality of the title.
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.
Every blog post should include a human readable date. In fact, this extends to almost anything online and even offline. Timestamps are hard to read.
Use date and time:
Every blog post should include the time it has been created. In fact, this extends to almost anything online and even offline. I was reading Jan Kremers post about blog timestamps and it was not immediately clear to me what time the post was created. Only when I did a look into the HTML source I discovered the time there.
I went back to RCS ($Id$) for my blog text files, so by default I get it all in UTC. That is the one thing I hate about git, it does not allow you to tag the file with ci information. So RCS tags my entries automatically.
But a non issue to me these days, I moved away from git due to changes Microsoft made after it purchased github. I am back "home" to RCS and anon ftp.
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 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.
Even for blogs it might matter if they are talking about breaking news. A timezone can roll a date forward/backwards one day.
I am talking about having a UX date/time standard for all of UX, not just blogs.
There is UX where knowing timezone is critical, ex: when analyzing logs, breaking news etc.
To keep things simple it would be great if everyone agreed to always attach TZ info to any date or time shown.
Furthermore, any blog/article that might not appear important at the time it's posted, might become important DUE to breaking news. So just put timezones everywhere an be done with it :)
I agree, but this is a result of both SEO and humans prioritizing “fresh” over “old” content, which led to the removal of timestamps - or in the case of news websites, eternally rolling artificial “last updated” timestamps on decade-old articles.
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.
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
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”).
> was reading Julia Evans post about nothing [my emphasis]
Off-topic, but is this a typo of "Nix" or a passive-aggressive jab at Julia for blogging about the tedium of actually getting anything to actual work in modern development?
It's gone now – Probably either accidental translation from German or intentional word joke ("nothing" in German and Dutch is pronounced similar to "nix");
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
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.
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!