This document defines an extension to the timestamp format defined in
This document defines an extension to the timestamp format defined in
Dates and times are used in a very diverse set of internet applications, all the way from server-side logging to calendaring and scheduling.
Each distinct instant in time can be represented in a descriptive text format
using a timestamp, and
This is already a pressing issue for applications that handle each instant with
an associated time zone name, to take into account things like DST transitions.
Most of these applications attach the timezone to the timestamp in a
non-standard format, atleast one of which is fairly well-adopted (
This document defines an extension syntax for timestamps as specified in
The extension suffix is completely optional, making existing
The format is compatible to the pre-existing popular syntax for attaching
time zone names to timestamps (
The format provides generalized way to attach any additional information to the timestamp.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in
Coordinated Universal Time as maintained since 1988 by the Bureau
International des Poids et Mesures (BIPM) in conjunction with
leap seconds as announced by the International Earth Rotation
and Reference Frames Service
Augmented Backus-Naur Form, a format used to represent
permissible strings in a protocol or language, as
defined in
The date/time format defined in section 3 of this document.
This term is used in this document to refer to an unambiguous representation of some instant in time.
A suffix which, when applied to a time, denotes a UTC offset of 00:00; often spoken "Zulu" from the ICAO phonetic alphabet representation of the letter "Z".
A time zone that is a included in the Time Zone Database (often called tz or zoneinfo) maintained by IANA.
For more information about time scales, see Appendix E of
This section discusses desirable qualities of formats for the timestamp
extension suffix and defines such a format that extends
The format should allow implementations to specify additional important information in addition to the bare timestamp. This is done by allowing implementations to include an informative suffix at the end with as many tags as required, each with a key and value separated by an equals sign. The value can be a hyphen delimited list of multiple values.
In case a key is repeated or conflicted, implementations MUST give precedence to whichever value is positioned first.
Since the suffix can include all sorts of additional information, different standards bodies/organizations need a way to identify which part adheres to their standards. For this, all information needs to be namespaced. Each key is therefore divided into two hyphen-separated sections: the namespace and the key. For example, the calendar as defined by the Unicode consortium could be included as u-ca=<value>.
All single-character namespaces are reserved for BCP47 extensions recorded in the BCP47 extensions registry. For these namespaces:
Case differences are ignored.
The namespace is restricted to single alphanum, corresponding to extension singletons ('x' can be used for a private use extension).
In addition, for CLDR extensions:
There must be a namespace-key and it is restricted to 2 alphanum characters.
A suffix-value is limited to 3*8alphanum.
Multi-character namespaces can be registered specifically for use in this format. They are assigned by IANA using the "IETF Review" policy defined by [RFC5226]. This policy requires the development of an RFC, which SHALL define the name, purpose, processes, and procedures for maintaining the subtags. The maintaining or registering authority, including name, contact email, discussion list email, and URL location of the registry, MUST be indicated clearly in the RFC. The RFC MUST specify or include each of the following:
The specification MUST reference the specific version or revision of this document that governs its creation and MUST reference this section of this document.
The specification and all keys defined by the specification MUST follow the ABNF and other rules for the formation of keys as defined in this document. In particular, it MUST specify that case is not significant and that keys MUST NOT exceed eight characters in length.
The specification MUST specify a canonical representation.
The specification of valid keys MUST be available over the Internet and at no cost.
The specification MUST be in the public domain or available via a royalty-free license acceptable to the IETF and specified in the RFC.
The specification MUST be versioned, and each version of the specification MUST be numbered, dated, and stable.
The specification MUST be stable. That is, namespace keys, once defined by a specification, MUST NOT be retracted or change in meaning in any substantial way.
The specification MUST include, in a separate section, the registration form reproduced in this section (below) to be used in registering the namespace upon publication as an RFC.
IANA MUST be informed of changes to the contact information and URL for the specification.
IANA will maintain a registry of allocated multi-character namespaces. This
registry MUST use the record-jar format described by the ABNF in
Failure to maintain this record, maintain the corresponding registry,
or meet other conditions imposed by this section of this document MAY
be appealed to the IESG
'Identifier' contains the multi-character sequence assigned to the namespace. The Internet-Draft submitted to define the namespace SHOULD specify which sequence to use, although the IESG MAY change the assignment when approving the RFC.
'Description' contains the name and description of the namespace.
'Comments' is an OPTIONAL field and MAY contain a broader description of the namespace.
'Added' contains the date the namespace's RFC was published in the
"date-full" format specified in
'RFC' contains the RFC number assigned to the namespace.
'Authority' contains the name of the maintaining authority for the namespace.
'Contact_Email' contains the email address used to contact the maintaining authority.
'Mailing_List' contains the URL or subscription email address of the mailing list used by the maintaining authority.
'URL' contains the URL of the registry for this namespace.
The determination of whether an Internet-Draft meets the above conditions and the decision to grant or withhold such authority rests solely with the IESG and is subject to the normal review and appeals process associated with the RFC process.
The following rules extend the ABNF syntax defined in
Here are some examples of Internet extended date/time format.
This represents 39 minutes and 57 seconds after the 16th hour of December 19th, 1996 with an offset of -08:00 from UTC. Note that this is equivalent to 1996-12-20T00:39:57Z in UTC.
This represents the exact same instant as the previous example but additionally specifies the human time zone associated with it ("Pacific Time") for time-zone-aware implementations to take into account.
This represents the exact same instant but it informs calendar-aware implementations that they should project it to the Hebrew calendar.
This timestamp utilizes the private use namespace to declare two additional pieces of information in the suffix that can be interpreted by any compatible implementations and ignored otherwise.