A Guide to the HTML5 ‘time’ Element

By Aurelio De Rosa

Time – one of the few known things that is infinite. Human beings, as well as animals and plants, have dealt with time since the beginning of their existence.

On the web this need isn’t different. Even in this medium, we need to communicate to other people that something happened at a certain point, on a specific date, or in relation to another set time.

Prior to HTML5 we had no element to semantically mark up a date or time. In recent years, other solutions, most notably Microformats and Microdata, have tried to fill this gap for specific situations (date of birth, publication of a book, and so on).

In this article I’m going to cover HTML5’s <time> element, which helps address the need just discussed.

What’s the <time> Element?

The <time> element was introduced in the HTML5 spec in 2009. It was then dropped in 2011 in favor of <data>. Then <time> was reintroduced, and then improved to allow new date/time formats. From this you can see that specifications can be quite controversial.

The <time> element represents a date and/or a time in the Gregorian calendar. It’s an inline element (like <span> and <a>) and must have a closing tag (like <div> and <span>). When used in its simplest form, the content of the element must be a valid date and/or time string.

An example is shown below:

<!-- 1st February 2009 -->

In the code above, I’m defining a date, specifically February 1, 2009. The format employed in the code (yyyy-mm-dd) should be familiar to you if you have spent some time on Linux but, as we’ll see later in this article, this isn’t the only valid format.

In the first draft of the specifications, precise dates were one of the few formats you could write. For example, you couldn’t specify a date like “November 2014” or “476” (the start of the Middle Ages). This was a big issue for several cases like the dating of a painting or a historical event because a precise date isn’t known.

Fortunately, this type of date is now permitted in the spec. So today we can describe a given month of a year without a day:

<!-- January 2014 -->

The datetime Attribute

The specification for the <time> element also standardized an attribute called datetime.

While writing dates in the formats discussed in the previous section works in some countries/cultures, it doesn’t suit others. For example, Italians write dates using the format dd/mm/yyyy. Therefore, showing a date in another format may lead to confusion.

This issue can be easily solved using the datetime attribute of the <time> element. It’s an optional attribute that contains the information in a machine readable format, like those seen in the examples, allowing us to write the content of the element in any way we like.

In fact, if datetime isn’t specified, the content must be in one of the valid date/time formats, otherwise we can use it as we want. This is great because it allows us to write code as follows:

The next meeting is scheduled for <time datetime="2014-10">October</time>.

Or even:

The next meeting is scheduled for <time datetime="2014-10">next month</time>.

Both these examples have date content that isn’t machine readable according to the specification, but they are acceptable because of the presence of the datetime attribute, which does use a valid format.

At first glance, this might seem odd. But the content of the <time> element has been designed to serve human beings, not machines. Besides, this fact allows for the internationalization of the dates. For example:

<!-- Same message as before but in Italian -->
Il prossimo incontro è programmato per <time datetime="2014-10">il mese prossimo</time>.

In the code above, we have the same message as before, but in Italian.

The pubdate Attribute

The first drafts of the specification defined a pubdate attribute for the <time> element. This attribute was a Boolean indicating that a given date was the publication date of the parent <article> element or, if in the absence of a parent <article> element, of the whole document.

For example, you could write:

  <h1>A good title</h1>
  <p>This is the content of a great article.</p>
    <p>Article published on <time datetime="2014-09-05" pubdate>September the 5th, 2014</time>

In this case, September 5, 2014 would be the publication date of this “article”.

I’ve been a great fan of this attribute since I learned about it but, unfortunately, it was removed from the spec. This decision has created a big problem because a lot of people (including me) use the publication date to judge the freshness and the relevance of an article or news piece. While it’s true that you can still access the page of an article and view the publication date, we need a standard way for a machine to read the date.

At the moment there isn’t an attribute that replaces pubdate, but you can employ the BlogPosting schema, and specifically the datePublished value, as illustrated below:

<article itemscope itemType="">
  <h1 itemprop="headline">A good title</h1>
  <p itemprop="articleBody">This is the content of a great article.</p>

    <p>Article published on <time datetime="2014-09-05" itemprop="datePublished">5th September 2014</time>

Now that you have a complete overview of the <time> element, let’s see the several formats allowed.

The valid formats for the content of the <time> element in absence of the datetime attribute, and for the datetime attribute itself are described in the following sections.

A Valid Month

This should be a string specifying a specific month of a year in the form of yyyy-mm. For example:

<!-- September 2014 -->

A Valid Date (Day of the Month)

This should be a string specifying a precise date in the form of yyyy-mm-dd. For example:

<!-- 16th September 2014 -->

A Valid Yearless Date

This should be a string specifying a month and a day without a year in the form of mm-dd. For example:

<!-- 29th June -->

A Valid Time

This should be a string specifying a time without a date and using the 24-hour format, in the form of HH:MM[:SS[.mmm]] where:

  • H stands for hours
  • M stands for minutes
  • S stands for seconds
  • m stands for milliseconds
  • The square brackets indicate the parts that are optional

An example of this format is shown below:

<!-- 16 hours and 10 minutes
    (or 4 hours and 10 minutes pm) -->
<time datetime="16:10">afternoon</time>

Another example is:

<!-- 18 hours, 20 minutes, and 30 seconds
    (or 6 hours, 20 minutes, and 30 seconds) -->

A Valid Floating Date and Time

This format is present in the W3C spec, but not in the WHATWG version. This should be a precise date and time in the format yyyy-mm-ddTHH:MM[:SS[.mmm]] or yyyy-mm-dd HH:MM[:SS[.mmm]]. For example:

<!-- 16th September 2014 at 18 hours,
    20 minutes, and 30 seconds -->
<time datetime="2014-09-16T18:20:30">Tuesday at 18:20</time>

A Valid Time Zone Offset

This should be a string representing a time zone offset. For example:

<!-- GMT+1 (like Italy) -->

A Valid Global Date and Time

This should be a string representing a complete date, including time and time zone. For example:

<!-- 16th September 2014 at 18 hours,
    20 minutes, and 30 seconds in a 
    time zone of GMT+1 (like Italy) -->

A Valid Week

This should be a string representing a week of a year. For example:

<!-- The 18th week of 2014 -->

A Valid Year

This should be a string representing a year. For example:

<!-- 2014 -->
<time datetime="2014">this year</time>

A Valid Duration String

This should be a string representing a duration. A duration can start with the prefix “P”, standing for “period”, and use a “D” to mark days. For example:

<!-- A duration of four days -->
<time datetime="P4D">four days</time>

In case you need to further specify the period, after the “D” you can add a “T”, standing for “time”, and use “H” for hours, “M” for minutes and “S” for seconds. Like this:

<!-- A duration of four days,
    four hours, and three minutes -->
<time datetime="P4DT4H3M">four days</time>

This format also allows you to specify one or more duration time components.


The current specification has some limitations in what you can define with the <time> element. One of these limitations is that you can’t indicate date ranges. So if you are writing a post about a conference that lasts more than one day, for example from June 26, 2014 to June 28, 2014, you have to use two <time> elements. A good example can be found in the speaking page on my website where I use the <time> element as shown below:

<time datetime="2014-06-28">26<span class="hidden">June 2014</span></time>-<time datetime="2014-06-28">28 June 2014</time>

Another limitation is that you can’t use the <time> element to represent dates before the Common Era.

Browser Support

Based on the <time> element article on MDN, this element is supported in:

  • Chrome 33+
  • Firefox 22+
  • Internet Explorer 9+
  • Opera 22+
  • Safari 7+

However, there is not much to worry about in older browsers. In fact, in case it lacks support for this element the browser will simply display it as an unknown inline element.


If you haven’t started using the <time> element in your pages, I hope this guide has inspired you to do so.

For more info, here are some relevant links:

This article is also available in Portuguese on Tableless

  • da-newton

    What’s the benefit of using the time element? It lookalike it is helpful for search engines to steal content, but doesn’t do anything for site visitors. Or have i completely missed something?

    • Hiro

      Ya. Agree, what is the objective?

    • Will Webb

      exactly what I was thinking – what benefit would this have for us as developers as I can only see crawlers benefiting?

      • Aurelio De Rosa

        In addition to this, I can see the use with calendars. You could create a script able to detect certain snippets of code and add event to your calendar.

    • Thomas Semmler

      Accessibility of course :D

      • david ascher

        so what would screen reader software do with this

        The next meeting is scheduled for next month.

        Would it say “the next meeting is scheduled for 2014-10” or “the next meeting is scheduled for next month” ? Why would you want it to say ‘2014-10’ rather than ‘next month’?

        • Thomas Semmler

          it might be able to say “next month”, if it has the information about the time itself. But “next month” (written) is not an information about time, the screenreader would just interpret it as normal text. Imagine, the text gets read seven months later, the screen reader could interpret this particular passage, and say “6 months ago”, instead of just reading the plain text “next month”.

          I know what you want to say with this, and I agree, but providing the semantic structure to the text makes the content definitely future proof. With things like Siri, you don’t know, if you wont be able to have the text read by the screenreader, make it stop and tell it to add the time to your calender and set up a reminder.

          But I’m weird. I like semantic elements for the sake of semantic itself.

          • david ascher

            “next month” is information about time if the element create or publish date is known, isn’t it? How would the screen reader know to say “six months ago” rather than “October, 2014”?

    • Aurelio De Rosa

      Well, you say “steal” content, I think “index” content.

      • david ascher

        so polite.

    • LouisLazaris

      Ideally, it would be nice if the time element was added to this page, which outlines the accessibility benefits of the different HTML5 elements:

      They do have the date/time inputs, but no time element. That’s probably because it was dropped and then added again. I’ve opened an issue on the GH repo, but not sure how well maintained that is.

  • Michael C.

    Am I missing something, or does not provide any way to indicate days of the week? For example, it’d be nice to be able to markup a weekly meeting schedule as Mondays at 10am or something similar…

    • Aurelio De Rosa

      You’re right is saying that this kind of dates are not allowed.

  • HenriHelvetica

    cool write up. Was hoping for something more exciting w/ this tag.

  • Eric Lin

    Doesn’t sound very exciting for developers or site readers, as I don’t see the beneficial for both end of the players on the web page, apart from bots..



Learn Coding Online
Learn Web Development

Start learning web development and design for free with SitePoint Premium!

Get the latest in Front-end, once a week, for free.