The element should do something(nolanlawson.com)
nolanlawson.com
The element should do something
https://nolanlawson.com/2025/12/14/the-time-element-should-actually-do-something/
34 comments
A special place in hell is reserved for Stack Overflow’s recent redesign, which shows “Over a year ago” both for comments that are 13 months old and for those that are 13 years old.
> I always get frustrated when I see a 7 months ago, or X years ago, the math is always inconsistent when they round it. So when something is more than 3 days old, I display the actual date.
What especially makes me angry is dev tools doing this.
No, Github, Circle CI or Google Console [1] and others. I need to see actual timestamps on commits, PRs, merges, logs etc. not the bullshit "7hrs ago" when I'm trying to find out what broke.
[1] At one point a few years back their log viewer would show this. Someone actually implemented it because showing this is more work than actual proper timestamps.
What especially makes me angry is dev tools doing this.
No, Github, Circle CI or Google Console [1] and others. I need to see actual timestamps on commits, PRs, merges, logs etc. not the bullshit "7hrs ago" when I'm trying to find out what broke.
[1] At one point a few years back their log viewer would show this. Someone actually implemented it because showing this is more work than actual proper timestamps.
The way that this is handled on most websites is that you show "X time ago" but you can hover over the time to get the full timestamp. For example, that's how it's handled here on Hacker News and Reddit.
The relative-time labeling bit HN in the ass this week during its outage (<https://news.ycombinator.com/item?id=46301921>), when hours-old comments were displayed as "n minutes ago", with n ranging from 0 to low-single-digits.
This made identifying the duration of the outage somewhat more difficult.
(HN does display the precise time in a title text for the timestamp which typically appears on hover, though you'd need to know that that's in UTC.)
This made identifying the duration of the outage somewhat more difficult.
(HN does display the precise time in a title text for the timestamp which typically appears on hover, though you'd need to know that that's in UTC.)
I honestly don't understand why it's ever useful to die show relative timestamps over absolute ones. It's not hard to look at a date or time and understand how far back it was; it's not even that I can do the math to figure out the relative time, but that the relative version isn't even worth bothering to calculate because the absolute one is just as intuitive. If it's currently February 20XX and I see a timestamp of July 20XX-1, I know how long it's been since then, and I don't care about the number of months. If it's February and I see the timestamp "7 months ago" I don't immediately know it's July without at least doing some small amount of thinking, like "okay, a year before five months from now, so July" (which is especially silly because now I'm having to lean even more into relative times just to be able to get back to the absolute date). Seeing the exact date and also potentially know other pertinent facts like the season ("that picture was from the summer"), holidays ("it must be from the 4th of July barbecue"), etc.
Is there something I'm missing here about why people might prefer relative timestamps? I genuinely can't tell if everyone kind of universally hates them or if this is one of those things where my brain just works differently than a lot of other people.
Is there something I'm missing here about why people might prefer relative timestamps? I genuinely can't tell if everyone kind of universally hates them or if this is one of those things where my brain just works differently than a lot of other people.
> Is there something I'm missing here about why people might prefer relative timestamps?
I think most people are uncomfortable parsing timestamps for small-interval differences, e.g. `2025-12-19T16:28:09+00:00` for "31 seconds ago".
For larger intervals, I agree that timestamps are more useful. "1 day ago" is a particular bugbear of mine. One day meaning, 13 hours, or meaning 35 hours? Sometimes that's important!
The original advice when relative timestamps became a thing was to choose based on the activity level of the content. If new content is constantly appearing and older stuff fades out of relevance quickly, then choose relative timestamps. Otherwise, use absolute timestamps.
The worst is inconsistency, and the best is sometimes both (when presented in a discoverable and convenient way -- hover text used to be that way, but this degrades on mobile).
I think most people are uncomfortable parsing timestamps for small-interval differences, e.g. `2025-12-19T16:28:09+00:00` for "31 seconds ago".
For larger intervals, I agree that timestamps are more useful. "1 day ago" is a particular bugbear of mine. One day meaning, 13 hours, or meaning 35 hours? Sometimes that's important!
The original advice when relative timestamps became a thing was to choose based on the activity level of the content. If new content is constantly appearing and older stuff fades out of relevance quickly, then choose relative timestamps. Otherwise, use absolute timestamps.
The worst is inconsistency, and the best is sometimes both (when presented in a discoverable and convenient way -- hover text used to be that way, but this degrades on mobile).
To clarify, I don't mean to literally imply an exact timestamp format. Showing something like "December 19, 2025 4:28 PM" or "19 December 2025 16:28" seems strictly better to me than "31 seconds ago" because it doesn't either become inaccurate quickly or require having the page update in real-time.
Posts for one thing like yours an hour ago as of this post. Sometimes people want to see how old content is at a glance. Like how long ago did someone log in?
I guess I just don't find the relative timestamp to be a more intuitive way of seeing that. If I see today's date and a time this morning, I don't need to "translate" that into an exact number of hours because "12 hours ago" isn't more meaningful to me than "this morning", an "2 minutes ago" is likely going to be wrong quickly (or require a technical measure to keep accurate, and given that the relative timestamp already arguably is more work to implement, that's now two extra things added to try to solve a problem that I don't really understand to exist in the first place).
Having thought through a bunch of different orders of magnitude of time (time in the past measured in seconds, minutes, hours, days, weeks, and years), I'm confident that I'd personally find the actual date and time to be more intuitive in every single one of them. What I'm not confident in is whether that would be the case for everyone else or not. I don't think there would be anything wrong with someone feeling differently than me, and if it turns out I'm in the minority, I wouldn't have any trouble accepting it, but it feels so fundamentally disconnected with the way I think about things that I have trouble conceiving of it other than as a hypothetical.
Having thought through a bunch of different orders of magnitude of time (time in the past measured in seconds, minutes, hours, days, weeks, and years), I'm confident that I'd personally find the actual date and time to be more intuitive in every single one of them. What I'm not confident in is whether that would be the case for everyone else or not. I don't think there would be anything wrong with someone feeling differently than me, and if it turns out I'm in the minority, I wouldn't have any trouble accepting it, but it feels so fundamentally disconnected with the way I think about things that I have trouble conceiving of it other than as a hypothetical.
Take a look at GitHub’s <relative-time> element - works great as a progressive enhancement: https://github.com/github/relative-time-element
Looks like a bigger version of something I built. In my case I built it as a progressive enhancement to `<time>` itself (like `<time is="relative-time">`), which also potentially makes it easier for it to gain features if the tag gains features. Of course, the most obvious (and disappointing) trade off to that approach is lack of Safari support [1].
[1] https://developer.mozilla.org/en-US/docs/Web/HTML/Reference/...
[1] https://developer.mozilla.org/en-US/docs/Web/HTML/Reference/...
Wouldn't it make sense if the content of it could be auto-generated as well for the users' locale directly with no need for JS?
Either as a date in the example "4 days ago" or "in 2 days, 2 hours and 28 seconds" for future events. This requires some control for granularity to control for how precise you want it to be and what to omit.
"a few seconds ago", "3 seconds ago", "less than a minute ago".
Should support a shortform that can act as a countdown timer "00:00:56" or "00:56".
Either as a date in the example "4 days ago" or "in 2 days, 2 hours and 28 seconds" for future events. This requires some control for granularity to control for how precise you want it to be and what to omit.
"a few seconds ago", "3 seconds ago", "less than a minute ago".
Should support a shortform that can act as a countdown timer "00:00:56" or "00:56".
Then write a browser plugin that does these things to the <time> element.
Personally I always use the <time> element when providing date or time. Properly localized with Intl.DateTimeFormat and ISO string formatted in the datetime attribute. I do it mostly because it is free. For a developer writing <time> instead of <span> makes no difference. <time> is easier to target in tests, and maybe my users has a browser plugin that can quickly e.g. add a thing to their day planner app from a <time> element.
Personally I always use the <time> element when providing date or time. Properly localized with Intl.DateTimeFormat and ISO string formatted in the datetime attribute. I do it mostly because it is free. For a developer writing <time> instead of <span> makes no difference. <time> is easier to target in tests, and maybe my users has a browser plugin that can quickly e.g. add a thing to their day planner app from a <time> element.
It's wild to me that it doesn't even generate a tooltip by default.
I wrote a small custom component using Lit[1] for use on my personal blog[2]. It provides some clever logic around timestamps, showing them in the readers time zone and with their locale formatting. Should that fail, there's a fallback to just plain text. When working with shortened, relative, or whatever else timestamps, the full value is available, in iso 8601, as the title text. I've used them all over the site, and they work rather nicely
A funny story about developing them. I had a friend in India check them to see if they worked on his computer/browser combo, and for a short period of time I was incredibly frustrated at the screenshots he was sending back. They displayed nearly the exact same time as mine, but shifted by half an hour. After a bit of thought, I realized his locale formatting didn't use a meridian indicator, and his time zone was 12:30 different than mine, so 9pm was 9:30 in the morning for him
[1]: https://github.com/paradox460/pdx.su/blob/main/assets%2Fjs%2...
[2]: https://pdx.su
A funny story about developing them. I had a friend in India check them to see if they worked on his computer/browser combo, and for a short period of time I was incredibly frustrated at the screenshots he was sending back. They displayed nearly the exact same time as mine, but shifted by half an hour. After a bit of thought, I realized his locale formatting didn't use a meridian indicator, and his time zone was 12:30 different than mine, so 9pm was 9:30 in the morning for him
[1]: https://github.com/paradox460/pdx.su/blob/main/assets%2Fjs%2...
[2]: https://pdx.su
I try to include it whenever possible, and I long for a future where it's universal, so any date shown could be displayed in 8601/3339, and thus never in the five or so random date formats I have to deal with, not including relative ones. I doubt its going to happen though, since even excluding the relative dates, most sites seems to write their dates according to their own locale, which does make sense and is the best option if you're not going to provide any options to the user, and it's the option that makes the least amount of people complain (no American is going to complain about seeing December 19th 2025, and no German is going to complain about 19. Dezember 2025, and not that many are even going to complain about 19.12.2025).
I agree it should do something, which might be configurable by the end user and implementation dependent. For example, a browser might have an option to display the time converted into your preferred time format and time zone. If the operating system environment has some way to specify that some text refers to date/time and can be used with other software in this way, then it would be possible to do that, too.
(My own Scorpion document format is intended to include this capability, as well as the ability to specify other things (e.g. units of measurement, international telephone numbers, how a word is pronounced, languages, etc) to be handled in similar ways, but it is not currently fully defined.)
(My own Scorpion document format is intended to include this capability, as well as the ability to specify other things (e.g. units of measurement, international telephone numbers, how a word is pronounced, languages, etc) to be handled in similar ways, but it is not currently fully defined.)
Similar gripe of mine, why doesnt input `datetime-local` add the timezone on the client side...
> Post published 4 hours ago
Am I the only one who dislikes these relative times and prefers absolute date stamps?
Especially "1 year ago" (for something that was 23 months ago)
Am I the only one who dislikes these relative times and prefers absolute date stamps?
Especially "1 year ago" (for something that was 23 months ago)
Relative times are nice for recent times (e.g. "5 minutes ago" is better than "2025-12-18 13:03"), but they should "decay" into absolute times for anything that isn't fairly recent - like a week or two, perhaps.
It varies by use case. I can think about e.g. an SRS flash card where you next review is in 2 years. I honestly don‘t care if 2 years here means 21 months or 28 months, and I especially don‘t care if the next review is on 21st of February 2028 at 13:52. All I want to know is that the next review is so far in the future it may not actually happen.
That's a fair point. I'm thinking of the use case of formatting a past date on something like a social media post/comment. (For example, a comment on HN - which uses a rather long cutoff for relative dates.)
I agree with you, I also prefer absolute date stamps, including because it might be printed out, etc. However, the <time> command would allow that to work, if it is implemented in a way that allows that to work.
[deleted]
It is particularly annoying in a screenshot or printed document. I rarely print onto paper, but occasionally, I will "print" an interesting blog post into a PDF.
I like it but I think the granularity needs to be fixed. For example, the cutoff points should be 21+ months -> 2 years instead of 13+ months -> 1 year.
So basically you want the cutoff to be > 1.66 of the next unit before you display in that unit. That means 40 hours, 2 days; 11 days, 2 weeks; 6 weeks, 2 months; 20 months, 2 years.
I'm annoyed by things moving unbidden, especially in clickable interfaces. This element being all over Slack, chat apps, etc. means that things are always shifting around slightly and at unpredictable times.
It has done nothing for so long that it may now be impossible to make it do something useful.
Tooltips are struggling on mobile.
bring back <blink> more like ittt
I always get frustrated when I see a 7 months ago, or X years ago, the math is always inconsistent when they round it. So when something is more than 3 days old, I display the actual date.