A tag to display date and/or time to the user in his preferred format.

[lostmsu]

Considering most web pages now are consumed all around the world, it would make sense to have an HTML-only solution to display some globally specific point in time (relativity jokes aside) to the user in user's preferred format and time zone.

As a server author, I mostly store my timestamps either in UTC, or with timezone info attached. Neither of them would be helpful to a user, who is in a different timezone.

There are two common approaches as to how to solve this simple task right now: server-side rendering, and JavaScript-based rendering.

The biggest disadvantage of the first one is a privacy problem, as it forces the user to expose his timezone to the server. Also, rendering different time for different users negatively affects page caching.

The problem with JavaScript-based approach is, of course, JavaScript. It can be disabled, or accidental errors, which happen elsewhere, might mislead user (e.g. if they end up seeing mixed adjusted and non-adjusted time stamps). Plus, it has to be implemented/properly used almost in every product.

That kind of tag would be useful on almost every website, Facebook, Youtube, and this very page included.

IMHO, <time> tag can be reused for that purpose, if left empty, datetime is set, and some attribute set to a value, describing the desired format of the display. For example, <time datetime='2017-03-02T07:02:20Z' format='date-only'> to show '02-03-2017' to people with French locale. And 'short-time' could show 08:02 for UTC+1.

[domenic]

This is a reasonable feature request, in my personal opinion. The best way to make progress on this sort of proposal is to create a library, probably using the custom elements feature already in the spec, and get widespread adoption across many sites. If that happens, then there's clear demand for such a feature, and implementers are more likely to consider it.

One of the reasons such a step is important, instead of just saying "a bunch of sites do something like this already", is to show that it's possible for a single API to serve all those different sites. Right now I definitely don't see GitHub, Facebook, YouTube, and almost every website using the same date formatting. Maybe that's because it's technically too hard---in which case creating such a library, and asking them to use it, would be a good way to prove that this is something the browser should help with. But maybe it's because they have specific product decisions which prevent them from all converging---in which case adding such a feature to the browser would be counterproductive.

[annevk]

Whenever this came up in the past an argument was made that this is better handled by CSS, which seems somewhat reasonable if we're talking about presenting data in a different way.

[Xiphe]

I was also thinking about this and wondered why there aren't low level solutions for this.

In addition to the original use case this could also be used to communicate relative times like "tomorrow morning" to someone from around the globe (medium: chat, calendar)

Have there been any developments here?

[domenic]

There are low-level solutions to this; see https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Intl/DateTimeFormat (format a date/time in any language) + navigator.language (get the user's preferred language).

This remains unable to serve the use case of users which have customized their date format to something non-default for their language. Unfortunately exposing that level of information is a really big fingerprinting risk, and probably serves only a tiny minority of users, so it's unlikely to get worked on. (A large number of programmers do this, to get YYYY-MM-DD dates despite living in, e.g., MM/DD/YYYY countries. But I believe it's fairly rare outside of such cases. I don't have proof, though.)

Anyway, this issue is really about a high-level feature, not a low-level feature.

[Xiphe]

Thanks for the update @domenic!

I probably used high/low-level in a wrong way. As a JS developer I meant "low-level" like "lower then the level I operate at" like browser/os build-in. But I now realise that this was biased from my perspective, sorry in case that was misleading. Let me rephrase my first sentence: I'm also curious about this and interested to read up discussions about providing such a feature on html/css level.

Your comment about how to approach this was really helpful and inspiring to me. Will do some research into that direction

[hsivonen]

In addition to a non-JS solution to this probably belonging in CSS conceptually (the JS solution belongs in the intl API), the requested feature has the problem than when the date format of the user's locale and the typical date format of the language the page is in permute the fields without other indications, it's reasonable for the user to expect the dates to follow the conventions of the language of the page.

For example, if a user whose local convention is day first, month second reads American English content, it's reasonable for them to assume month first, day second if both appear as digits only in the context of American English page. Swapping the digits around is probably less helpful than forcing the month as text. If the page shows the month as unabbreviated text to everyone, there's no need for a Web Platform feature at all. (Abbreviated text may be problematic. Just today, YouTube told me that a video was posted in "Mar", and just to be sure that it meant March and not marraskuu, i.e. to confirm that it was not trying to be helpful as proposed here, I switched the YouTube UI language to see a second rendering of the date.)

[bahrus]

Since the related issue I raised was closed as a duplicate (which is reasonable), let me add to this issue my support for the recommendation that we provide the time tag some much needed tender loving care, and add support for all the options of intl.DateTimeFormat to the time tag, so that the text content can, when specified become a wrapper around applying this api based on the datetime attribute. I would think for backwards compatibility we wouldn't want to do anything different if left empty, but rather, we introduce a new attribute, something like "deriveFromDateTime", which would use toLocaleDateString() if no other formatting attributes are present, and use intl.DateTimeFormat if any of them are (e.g. dateStyle, timeZone, etc).

Not supporting this, to me, is an example of the mess that is web standards, where there seems to be a lack of reinforcement and consistency between disparate parts of the standard (microdata, semantic HTML, JavaScript api's, etc).

The demand for intl.DateTimeFormat has proven to be quite high, significantly outpacing the use of the time element. This probably reflects lack of developer awareness that the proper semantic way of displaying read only dates is (correct me if I'm wrong?) only via the time tag.

There are quite popular libraries that utilize intl.DateTimeFormat, such as react-intl that clearly doesn't make use of the time tag. Meaning the desire for a semantic way of formatting dates has been proven (to @domenic's concern), but that semantic way is proprietary, due to the WHATWG's lack of courage, leaving search engines in the dark.

If we want search engines to produce accurate results, which is good for the web and society (especially in our current times), we should do everything we can to nudge developers to take advantage of the semantic tags that have become part of the standard, rather than letting them wither and die out there, due to lack of a consistent, reinforcing message.

The argument that this is the proper role of css seems similarly misguided. Few if any css rules apply to a single tag, and there are plenty of tags (meter, progress), which could be accomplished via css, but which have correctly, I think, been given a semantic (HTML) vocabulary to describe how to achieve the desired output. Why undermine that story with dates?

[bathos]

I’ve ended up making custom elements for date/number values that are essentially “declarative Intl.FooFormat” in more than one codebase and they served me / others well, so my anecdotal personal experience aligns with what you’ve suggested here and elsewhere @bahrus. (And naturally, the Date ones used <time> inside).

However there aren’t any native HTML elements that really work like this today, right? The premise is text-like, but the text would be “introduced”, UA-controlled text; it could not be natively realized with exposed, mutable Text nodes (i.e. it would need to be analogous to text nodes in closed shadow DOM). The only existing things like this I can think of are CSS markers, CSS before/after content text, and perhaps textual parts of some complex UA input widgets in some browsers. So if implemented natively, it seems like there may be a bunch of questions with no obvious right answer on account of that novelty. The following interactions come to mind as “oh, hm...” things, but I bet there are more:

• The Range (text selection) API
• The Highlight API
• Text fragment directives (and find-in-page)
• To remain sound, innerText & textContent wouldn’t be able to reflect the UA-introduced text, just as they don’t reflect CSS marker text, afaict. If I’m correct about that, that could end up being a bit of a footgun/headscratcher given how much the introduced text of these elements would “feel” like “regular” text.

OTOH, creating custom elements for these was straightforward — and fortunately such solutions don’t need to have “polished” answers for questions like those (which a native solution can’t avoid addressing). For that reason, even though I like the idea of these elements and have found them very useful myself, I tend to think userland continues to be the best way to go for now. As @domenic mentioned earlier, if a userland solution saw widespread adoption, it might change the calculus. It would also provide real data about how to answer the hairier questions. And I don’t see how the absence of standardization movement on this is evidence of a “lack of courage,” personally 😄

[bahrus]

Good points, @bathos, and just realized:

Shoelace components, wraps time tag with intl.DateFormat, 460 million hits / month, so that would appear to satisfy @domenic's criteria for going forward.

[bahrus]

However there aren’t any native HTML elements that really work like this today, right? The premise is text-like, but the text would be “introduced”, UA-controlled text; it could not be natively realized with exposed, mutable Text nodes (i.e. it would need to be analogous to text nodes in closed shadow DOM).

I may be missing something, but I think it could work along the lines of the output element.

[bahrus]

Another web component that provides a wrapper around the time element: timestamp.

[bahrus]

Further confirmation that developers don't see the point of the time tag without formatting support.

[aphillips]

If something is done here, it should draw on I18N support and that should be consistent with at least Intl.DateTimeFormat (and its options). These will also be the options used by Unicode's forthcoming MessageFormat 2.0 and presumably be familiar to developers. If a compact notation is preferred, ICU's skeletons are a much better choice than "picture strings" (such as "YYYY-MM-DD").

[jyasskin]

There's a discussion of some options here in https://github.com/openui/open-ui/issues/1023, with feedback from the maintainer of https://github.com/github/relative-time-element.