Date formats and time zones don’t get enough press these days, do they? I’m here to change that and hopefully make your website more accessible to an international audience at the same time.
There has been a lot written about when the best time to publish an article or blog. I’d like to tackle a slightly different question you might not have known to ask: when is when? do your visitors know when that is?
You may have been writing the dates as you’ve always done and in the format taught to you at school. This is fine if all you write about is hyper-local news for a small local news gazette with no interest to anyone outside a 10-mile radius.
However, when publishing on the Web—be it intentional or not—you’re always writing to an international audience and should thus cater to the needs of an international and varied audience. Visitors to your website might not be too interested in when a page was published, but when they do they should have the information presented in a way they can understand.
Let’s use the third of February in 2001 as our example. Americans would write this date as 02.03.2001 or 02.03.01, whereas most parts of the world would write it as 03.02.2001 or 03/02/01. Putting local customs aside, the standard way of writing it for international exchange and computer interoperability is 2001-02-03, where the year comes first followed by month and day. This format has very usable properties for sorting and avoids confusion over the traditional regional date formats.
Unless otherwise agreed or requested by the recipient, always use the international format. This standard is defined in ISO 8601. To quote the online comic XKCD on the topic of calendar formats, ISO 8601 was published on 06/05/88 and most recently amended on 12/01/04.
XKCD thus elegantly summarizing the desperate need for one common global format. The W3C also has an excellent write-up on why you should use the international date format.
Given these problems, it can feel overwhelming and certainly feel attractive to just remove the date from the page. Not having a date of publication will lower the apparent trustworthiness of what you’ve written.
The practice of including the time of day that something was published should be reconsidered. For a blog or other website that only publishes a handful of pages per day, including the time of publication is too high a precision. It adds very little value to the page while increasing the complexity required to parse the date by humans and computers alike.
There are only four major variations in how to write times, but most websites fail to include information about what time zone the time refers to, and it further complicates the already difficult date format problem. Thus, a timestamp adds confusion and unnecessary headache when it just as well could be omitted.
Even when omitting the time stamp, it doesn’t free us entirely from dealing with time zones. Today’s date on 2015-07-24 at 00:00 UTC would be 2015-07-23 in CST (America) but stays 2015-07-24 in CET (Europe) while both imprecisely represents the exact same time. The webpage sent by the server should always have the date set in UTC and preferably in the new <time> element with a computer-parsable datetime attribute containing a ISO-8601 formatted representation.
The date format is shown inside the tag however, is meant to be a human representation of the time. To build on this example, the page could contain the date as such: <time datetime="2015-07-24T00:00Z">2015-07-24</time>. Using JavaScript, the date could then be swapped out on the fly with a local representation of the time in the correct time zone.
I’ve made an annotated version of such a time zone converting script that can be used to implement this on your sites. If JavaScript is disabled or is otherwise unavailable, converting a date manually from UTC is much easier than from other time zones as UTC’s offset is always 0.
Websites with a higher publication frequency than a few pages per day should include the time zone in any human-readable time representation. Remember that whatever you consider as the “local time” isn’t the local time for 23/24th of the global internet community.
Your little slice of the time zone pie can’t be your only priority when the audience is the world. Again, I recommend always publishing the time in UTC and using JavaScript to convert to the visitor’s local time zone. Even when converting to the user’s time zone, the time zone must be specified in a human-readable format to avoid confusion. Even when publishing at the “prime time window” around nine in the morning local time, the time stamp on the page should be in UTC. This doesn’t change when the page is published, but only how many can make sense of the publication time.
You may be cringing and thinking of whether your site visitors will understand this new format or not. Do consider that many of your visitors today don’t understand the date format you use and then reconsider. Keep in mind that the ISO 8601 format keeps creeping into common use in ever more places.
Many of the websites you visit, for example, likely use the format in their addresses (although with a slash instead of a hyphen separator). Online transaction receipts and any company doing international business increasingly use the ISO 8601 format. Your website could be part of the solution towards a global standard date format instead of one of the sites clinging to old and confusing formats.
Don’t wait! Update your website today and remove all ambigious date formats. Welcome a broader international audience with ISO 8601 formatted dates! It’ll probably only take you a few minutes.