Make WordPress Core

Opened 10 years ago

Closed 5 years ago

#29325 closed enhancement (maybelater)

Use <time datetime> tag in Post Date

Reported by: apiweb's profile Apiweb Owned by: sergeybiryukov's profile SergeyBiryukov
Milestone: Priority: normal
Severity: normal Version:
Component: Date/Time Keywords: has-patch
Focuses: Cc:


I think it would be interesting to use the tag <time datetime> in the dates, that WordPress uses (and extends it to the plugins).
For some this tag may be useless, but it has its value (besides not add anything visually), as interpreted by the machine, its use could be varied:

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 <time>16:00</time> to “16:00時”. Content aggregators can produce visual timelines of events.

Some links for this tag:
Mozilla Developer Network
HTML5 Doctor

Attachments (2)

29325.diff (1.5 KB) - added by diddledani 8 years ago.
add new function to include <time> tags if the theme declares support
the-time-tag.patch (1.2 KB) - added by Rarst 5 years ago.

Download all attachments as: .zip

Change History (17)

#1 @SergeyBiryukov
10 years ago

  • Component changed from General to Date/Time

#2 @chriscct7
9 years ago

  • Keywords needs-patch added

#3 @diddledani
9 years ago

I'd like to have a crack at tackling this as "my first bug", but I'm wondering if anyone has thoughts as to preventing conflicts with themes that add the tag themselves?

So far, I've thought about adding a filter which a theme could choose to unhook, but that would still cause breakage if a theme, which applies <time> itself, is left unchanged when the new code lands into core.

8 years ago

add new function to include <time> tags if the theme declares support

#4 @diddledani
8 years ago

  • Keywords has-patch added; needs-patch removed

The attached patch adds a new function hooked into the_date filter. This function will add <time datetime=""></time> tags if the active theme specifies that it supports this. Adding theme support is via html5/time-tag:

add_theme_support( 'html5', array( 'time-tag', ... ) );

#5 @Rarst
6 years ago

I don't think this can or should be handled by a filter, that would introduce a myriad of problems, such as:

  1. Any call that explicitly provides date format will be broken by it.
  2. Any call that goes through escaping before output will be broken by it.
  3. Even if theme explicitly opts in for it, there is no guarantee that any and all plugins running can handle it.

I am in favor of <time> tag being used in practice, but adding it to existing API is simply not viable.

We could consider a new dedicated function for it though.

#6 @Rarst
6 years ago

  • Keywords needs-patch added; has-patch removed

5 years ago

#7 follow-up: @Rarst
5 years ago

  • Keywords has-patch added; needs-patch removed

Added a small the_time_tag() function, defaulting to post published time but accepting arbitrary time stamp. Didn't want to go too crazy with flexibility, if someone needs to mess with it a lot they should probably just write their own tag logic.

Needs wp_date() merged #28636

Last edited 5 years ago by Rarst (previous) (diff)

This ticket was mentioned in Slack in #core-datetime by rarst. View the logs.

5 years ago

#9 @SergeyBiryukov
5 years ago

  • Milestone changed from Awaiting Review to 5.3
  • Owner set to SergeyBiryukov
  • Status changed from new to reviewing

#10 in reply to: ↑ 7 @SergeyBiryukov
5 years ago

Replying to Rarst:

Added a small the_time_tag() function, defaulting to post published time but accepting arbitrary time stamp.

Thanks for the patch! If the_time_tag() is intended for posts, it seems weird that it doesn't accept a $post parameter, like get_the_date(), get_the_time(), etc.

function the_time_tag( $format = '', $timestamp = null ) {
function get_the_date( $d = '', $post = null ) {
function get_the_modified_date( $d = '', $post = null ) {
function get_the_time( $d = '', $post = null ) {
function get_the_modified_time( $d = '', $post = null ) {
function get_post_time( $d = 'U', $gmt = false, $post = null, $translate = false ) {
function get_post_modified_time( $d = 'U', $gmt = false, $post = null, $translate = false ) {

Would it make more sense to pass $post as a second parameter, instead of $timestamp, for consistency with the other functions?

If it's intended as a general purpose function, then I think it should be just that, and something like the_post_time_tag() could wrap it to display a post time.

#11 @Rarst
5 years ago

get_ retrieval functions typically allow changing post context, the_ template tags typically don't and are just meant for the loop.

I considered implementing get_ "level" for this one, but since it returns HTML markup, I didn't want to encourage passing that around.

I think making it general purpose function makes it a little too hard to use as a "just works" template tag, so maybe two different functions does make sense.

If it works out too clunky we could drop it too. This one isn't mission-critical.

Last edited 5 years ago by Rarst (previous) (diff)

#12 @diddledani
5 years ago

We do have precedent here:

The get_the_post_thumbnail returns HTML so it is not unexpected that other get_* functions can do the same IMO.

#13 @diddledani
5 years ago

argh, branfart *deleted my post*

Last edited 5 years ago by diddledani (previous) (diff)

#14 @Rarst
5 years ago

There is a lot of precedent in WP core for things that are generally not a good idea. :)

Looking at spec for the tag the generic helper would be... non-trivial. The thing supports not just times, but date-only, time-only, and duration string values. At which point we are busy building a complex PHP abstraction for a single HTML tag instead of just templating it.

Let's step back and consider this question — where in WP core or theme development do we need this implemented as dedicated function as opposed to templating this output?

I might be wrong, but it is my impression that value of this tag is in cases where it's used for specific purpose (such as specific script working with markup meant for it) rather than generically.

#15 @Rarst
5 years ago

  • Milestone 5.3 deleted
  • Resolution set to maybelater
  • Status changed from reviewing to closed

I think I am shelving this for now. It really is a non-trivial tag to implement generically, it's easy to template with existing API, and there is no outstanding functionality that needs a dedicated function for this.

Note: See TracTickets for help on using tickets.