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:

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:

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:

Or even:

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:

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:

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:

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:

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:

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:

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:

Another example is:

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:

A Valid Time Zone Offset

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

A Valid Global Date and Time

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

A Valid Week

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

A Valid Year

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

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:

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:

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

Limitations

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:

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

Browsers 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.

Conclusion

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:

• <time> Element on W3C
• <time> Element on WHATWG
• <time> Element on MDN
• <time> Element Wiki on WHATWG

This article is also available in Portuguese on Tableless

Source Link: http://www.sitepoint.com/html5-time-element-guide/