The semantics of time have been defined by just about every standards body you can shake an egg timer at. Even within the internet space you will find overlapping definitions and specifications from ISO, ECMA, IMC, W3C, IETF and the Dublin Core Metadata Initiative. And that's without getting into individual language APIs, frameworks and data models. Oh yeah and just for kicks, some standards contain their own temporal entities and definitions.

ISO 8601
This is the grandaddy of all temporal web standards and you'll find it referred to in every other specification. Originally released in 1988, ISO8601 defines a range of textual formats for the interchange of dates, times and time periods.

For all it's ubiquity, it is not without it's problems: parametrisation can be a little loose. For example it'll accept hour values between 0 and 24, and early versions were comfortable with the dropping of centuries from year definitions.

In reality no-one implements all of ISO8601 - it's just too loose to be practical. What happens is, a standards body defines a subset (or "profile") of the full standard, and sometimes another standard will include or be based upon a child standard. The diagram below shows the ISO8601 family tree of adoption.

For an overview of the various formats check out HackCraft's Date and Time Formats on the web.


When the W3C came to define their date and time standards they very sensibly choose to adopt a profile of ISO 8601. Favouring reliability over flexibility, they achieve this by enforcing a stricter simplified subset of ISO 8601.

The W3C's specification for RDF semantics contains a recommended XML datatype for date time: xsd:dateTime. This is also a profile of ISO 8601 and can be use to express a W3C-DTF in the XML format.

The Internet Engineering Task Force took a similar approach when defining RFC 3339 Date and Time on the Internet: Timestamps. This standard enforces a subset of W3C-DTF and is consequently the simplest of the three formats.

It's worth noting therefore that any date conformant with RFC 3339 will also be valid in W3C-DTF and ISO 8601. This was the primary reason for adopting it as the date time format for Atom syndication. Talking of syndication, beware of the older RSS specification which uses the same archaic datetime format used by email and HTTP. You can find this specified in RFC 822 and modified in 1989 by RFC 123 to enforce four digit years.

Calendaring and Scheduling

The original internet calendaring standard was vCalendar. This and vCard were co-developed initially by Apple, AT&T, IBM, and Siemens, before being passed to the Internet Mail Consortium in 1996. This textual format can contain temporal and descriptive data about an event or task.

iCalendar ( RFC 2445 )
In many respects iCalendar can be considered vCalendar 2.0. It supports all the features of vCalendar and has a similar textual structure. The advantage of using iCalendar over it's predecessor is that you can also exchange journal entries and information about the free-busy status of an entity.

This is a microformat implementation of iCalendar. Microformats are small XML documents that can be easily embedded, read and exchanged across the web. The microformat datetime-design-pattern page hosts an interesting discussion about the need for a machine and human readable date time format.

This is a proposed XML implementation of iCalendar.

RDF Calendar
This is a proposed RDF implementation of iCalendar.

Client side language specifications

There is currently no support for temporal elements in HTML, but one of the proposals in HTML 5 is for a time element. This would support dates and times in the Gregorian calendar as well as timezones.

ECMA 262 v3 (Javascript and Actionscript)
This is the standard that Actionscript and Javascript are derived from. The Date class is an implementation of the Gregorian calendar and although it models UTC, leap seconds are ignored. Some of these issues are under review and proposals are in motion to make changes in version 3.1 and version 4.0.