Internet-Draft | Timestamps Extended | December 2021 |
Sharma & Bormann | Expires 6 June 2022 | [Page] |
This document defines an extension to the timestamp format defined in RFC3339 for representing additional information including a time zone.¶
This note is to be removed before publishing as an RFC.¶
Status information for this document may be found at https://datatracker.ietf.org/doc/draft-ietf-sedate-datetime-extended/.¶
Discussion of this document takes place on the Serialising Extended Data About Times and Events (SEDATE) Working Group mailing list (mailto:sedate@ietf.org), which is archived at https://mailarchive.ietf.org/arch/browse/sedate/.¶
Source for this draft and an issue tracker can be found at https://github.com/ietf-wg-sedate/draft-ietf-sedate-datetime-extended.¶
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.¶
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.¶
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."¶
This Internet-Draft will expire on 6 June 2022.¶
Copyright (c) 2021 IETF Trust and the persons identified as the document authors. All rights reserved.¶
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.¶
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 [ISO8601] standardizes a widely-adopted timestamp format, which forms the basis of [RFC3339]. However, this format only allows timestamps to contain very little additional relevant information, which means that, beyond that, any contextual information related to a given timestamp needs to be either handled separately or attached to it in a non-standard manner.¶
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, at least one of which is fairly well-adopted [JAVAZDT]. Furthermore, applications might want to attach even more information to the timestamp, including but not limited to the calendar system it needs to be represented in.¶
This document defines an extension syntax for timestamps as specified in [RFC3339] that has the following properties:¶
This document does not address extensions to the format where the semantic result no longer is a fixed timestamp that is referenced to a (past or future) UTC time. For instance, it does not address:¶
However, the additional information provided that augments a fixed timestamp may be sufficient to detect an inconsistency between intention and the actual information given in the timestamp, e.g., between the additional timezone information given and the timezone offset recorded in the timestamp. For instance, such an inconsistency might arise because of:¶
While the information available is not generally sufficient to resolve the inconsistency, it may be used to initiate some out of band processing to obtain sufficient information for such a resolution.¶
In order to address some of the requirements implied here, future related specifications might define syntax and semantics of strings similar to [RFC3339]. Note that the extension syntax defined in the present document is designed in such a way that it can be useful for such specifications as well.¶
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.¶
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 [IERS]. From 1972 through 1987 UTC was maintained entirely by Bureau International de l'Heure (BIH). Before 1972 UTC was not generally recognized and civil time was determined by individual jurisdictions using different techniques for attempting to follow Universal Time based on measuring the rotation of the earth.¶
UTC is often mistakenly referred to as GMT, an earlier timescale UTC was designed to be a useful successor for.¶
Augmented Backus-Naur Form, a format used to represent permissible strings in a protocol or language, as defined in [RFC5234]. The rules defined in Appendix B of [RFC5234] are imported implicitly.¶
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 included in the Time Zone Database (often
called tz
or zoneinfo
) maintained by IANA.¶
Common locale data repository [CLDR], a project of the Unicode Consortium to provide locale data to applications.¶
For more information about time scales, see Appendix E of [RFC1305], Section 3 of [ISO8601], and the appropriate ITU documents [ITU-R-TF.460-6].¶
This section discusses desirable qualities of formats for the timestamp extension suffix and defines such a format that extends [RFC3339] for use in Internet protocols.¶
The format should allow implementations to specify additional
important information in addition to the bare timestamp.
This is done by defining tags, each with a key and
a value separated by an equals sign.
The key of a tag can be split into two parts by including a
hyphen/minus sign "-
"; the first part (including the "-
") can then
be used as a namespace.
The value of a tag can be a hyphen/minus delimited list of multiple values.¶
Out of these tags, applications can build an informative suffix at the end with as many tags as required.¶
Keys are case-sensitive. Values are case-sensitive unless otherwise specified.¶
In case a suffix repeats a key or otherwise contains conflicting tags, implementations MUST give precedence to whichever value is positioned first. I'd rather place a MUST NOT for this case, first. This definitely needs to be expanded into some general text about error handling.--- cabo¶
Suffix keys identify a namespace.
By including a hyphen/minus sign "-
", the namespace can be separated
from the rest of the key; if no hyphen/minus sign is included, the
whole key is the namespace.¶
For example, if "u-
" is a namespace for the Unicode consortium, a
calendar as defined by that consortium could be included as
u-ca=<value>
.¶
An IANA registry for namespaces can be used to allocate namespaces for specific applications, as defined in Section 4. Two namespaces are allocated by the present document:¶
In addition, for CLDR extensions: I don't know how this would be used, so I can't edit this text.--- cabo¶
Additional namespaces can be registered under an Expert review policy, providing a description for the intended use. This may be a general concept, or a specific organization that is intended to register keys within this namespace.¶
Actual keys are registered by supplying the information in Figure 1:¶
%% Identifier: Description: Comments: Added: RFC: Authority: Contact_Email: Mailing_List: URL: %%
'Identifier' contains the key name.¶
'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 key's definition was published in the "date-full" format specified in Figure 2. For example: 2004-06-28 represents June 28, 2004, in the Gregorian calendar.¶
'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 following rules extend the ABNF syntax defined in [RFC3339] in order to allow the inclusion of an optional suffix.¶
The extended date/time format is described by the rule
date-time-ext
.
date-time
is imported from Section 5.6 of [RFC3339], ALPHA
and
DIGIT
from Appendix B.1 of [RFC5234].¶
time-zone-initial = ALPHA / "." / "_" time-zone-char = time-zone-initial / DIGIT / "-" / "+" time-zone-part = time-zone-initial *13(time-zone-char) ; but not "." or ".." time-zone-name = time-zone-part *("/" time-zone-part) time-zone = "[" time-zone-name "]" namespace = 1*alphanum namespace-key = 1*alphanum suffix-key = namespace ["-" namespace-key] suffix-value = 1*alphanum suffix-values = suffix-value *("-" suffix-value) suffix-tag = "[" suffix-key "=" suffix-values "]" suffix = [time-zone] *suffix-tag date-time-ext = date-time suffix alphanum = ALPHA / DIGIT
Note that a time-zone
is syntactically similar to a suffix-tag
,
but does not use a suffix-key
and an equals sign.
This special case is only available for timezone tags.¶
Here are some examples of Internet extended date/time format.¶
1996-12-19T16:39:57-08:00
Figure 3 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 the same instant in time as 1996-12-20T00:39:57Z
, expressed in UTC.¶
1996-12-19T16:39:57-08:00[America/Los_Angeles]
Figure 4 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.¶
1996-12-19T16:39:57-08:00[America/Los_Angeles][u-ca=hebrew]
Figure 5 represents the exact same instant, but it informs calendar-aware implementations that they should project it to the Hebrew calendar.¶
1996-12-19T16:39:57-08:00[x-foo=bar][x-baz=bat]
Figure 6, based on Figure 3, 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.¶
Define a registry that can contain both namespaces and keys. Namespaces can be recognized by ending with a hyphen/minus. Actual keys do not. See Section 2.3 for the detailed information (to be edited).¶
The policy is "RFC required", "Specification Required", ???We need to define the policy for both namespaces and full keys.--- cabo [RFC8126].¶