A common UI pattern is something like this:
Post published 4 hours ago
People do lots of stuff with that “4 hours ago.” They might make it a permalink:
Post published <a href="/posts/123456">4 hours ago</a>
Or they might give it a tooltip to show the exact datetime upon hover/focus:
Post published <Tooltip content="December 14, 2025 at 11:30 AM PST"> 4 hours ago </Tooltip>
Note: I’m assuming some Tooltip component written in your favorite framework, e.g. React, Svelte, Vue, etc. There’s also the bleeding-edge popover="hint" and Interest Invokers API, which would give us a succinct way to do this in native HTML/CSS.
If you’re a pedant about HTML though (like me), then you might use the <time> element:
Post published <time datetime="2025-12-14T19:30:00.000Z"> 4 hours ago </time>
This is great! We now have a semantic way to express the exact timestamp of a date. So browsers and screen readers should use this and give us a way to avoid those annoying manual tooltips and… oh wait, no. The <time> element does approximately nothing.
I did some research on this and couldn’t find any browser or assistive technology that actually makes use of the <time> element, besides, you know, rendering it. (Whew!) This is despite the fact that <time> is used on roughly 8% of pageloads per Chrome’s usage tracker.
Update: Léonie Watson helpfully reports that the screen readers NVDA and Narrator actually do read out the timestamp in a human-readable format! So <time> does have an impact on accessibility (although arguably not a positive one).
So what does <time> actually do? As near as I can tell, it’s used by search engines to show date snippets in search results. However, I can’t find any guidelines from Google that specifically advocate for the <time> element, although there is a 2023 post from Search Engine Journal which quotes a Google Search liaison:
Google doesn’t depend on a single date factor because all factors can be prone to issues. That’s why our systems look at several factors to determine our best estimate of when a page was published or significantly updated.
In fact, the only Google documentation I found doesn’t mention <time> at all, and instead recommends using Schema.org’s datePublished and dateModified fields. (I.e., not even HTML.)
So there it is. <time> is a neat idea in theory, but in practice it feels like an unfulfilled promise of semantic HTML. A 2010 CSS Tricks article has a great quote about this from Bruce Lawson (no relation):
The uses of unambiguous dates in web pages aren’t hard to imagine. A browser could offer to add events to a user’s calendar. A Thai-localised browser could offer to transform Gregorian dates into Thai Buddhist era dates. A Japanese browser could localise to “16:00時”.
This would be amazing, and I’d love to see browsers and screen readers make use of <time> like this. But for now, it’s just kind of an inert relic of the early HTML5 days. I’ll still use it, though, because (as Marge Simpson would say), I just think it’s neat.
Read the Tea Leaves 
Posted by Jayden on December 14, 2025 at 4:44 PM
I use the time element for end-to-end tests.
I have a website that allows users to purchase subscriptions (monthly and yearly).
Since users are paying for a service, we need to make sure that the paid features are always working.
The website is also constantly evolving over time which has made it build up a lot of complexity. Changing one thing can cause unexpected issues elsewhere in unrelated sections in really surprising ways.
Complexity + must always work is a hard space to be in.
To catch unexpected changes and ensure that things keep working as expected, I made a test suite to get guarantees that features work correctly for logged out users, logged in users and logged in users with subscriptions.
We use the time element on our pages where users can see their own subscription’s details (e.g. invoice dates, purchased on, will renew on, etc…).
We display translated and localised times to the users inside a time element, and have a machine readable timestamp in an attribute on the time element. That way our tests can understand the timestamps and check it against the expected values regardless of the simulated user’s timezone, or language/locale.
Posted by Tim McCormack on December 15, 2025 at 6:16 AM
FYI, the text “<time>” in your title isn’t escaped in the feed, so it just says “The element should actually do something”.
Posted by Nolan Lawson on December 15, 2025 at 7:48 AM
Yes sadly this seems to be a WordPress thing. “The element should actually do something” is kind of funny though.
Posted by jokeyrhyme on December 15, 2025 at 10:56 AM
i’m intensely frustrated that it’s 2025 and i still have to manually convert dates and times to my local timezone :S
Posted by Weekly Reading List December 15 2025 – OZeWAI on December 15, 2025 at 2:01 PM
[…] The <time> element should actually do something Nolan Lawson: couldn’t find any browser or assistive technology that actually makes use of the <time> element. […]