Date and Time on the Internet: Timestamps with additional information
draft-ietf-sedate-datetime-extended-11

Serialising Extended Data About Times and Events               U. Sharma
Internet-Draft                                              Igalia, S.L.
Updates: 3339 (if approved)                                   C. Bormann
Intended status: Standards Track                  Universität Bremen TZI
Expires: 25 April 2024                                   23 October 2023

 Date and Time on the Internet: Timestamps with additional information
                 draft-ietf-sedate-datetime-extended-11

Abstract

   This document defines an extension to the timestamp format defined in
   RFC3339 for representing additional information including a time
   zone.

   It updates RFC3339 in the specific interpretation of the local offset
   Z, which is no longer understood to "imply that UTC is the preferred
   reference point for the specified time"; see Section 2.

   // (This "cref" paragraph will be removed by the RFC editor:) The
   // present version (-11) addresses comments received during IESG
   // review.

About This Document

   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/.  Subscribe at
   https://www.ietf.org/mailman/listinfo/sedate/.

   Source for this draft and an issue tracker can be found at
   https://github.com/ietf-wg-sedate/draft-ietf-sedate-datetime-
   extended.

Status of This Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

Sharma & Bormann          Expires 25 April 2024                 [Page 1]
Internet-Draft   Internet Extended Date/Time Fmt (IXDTF)    October 2023

   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 25 April 2024.

Copyright Notice

   Copyright (c) 2023 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.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   3
     1.1.  Scope . . . . . . . . . . . . . . . . . . . . . . . . . .   3
     1.2.  Definitions . . . . . . . . . . . . . . . . . . . . . . .   4
   2.  Updating RFC 3339 . . . . . . . . . . . . . . . . . . . . . .   7
     2.1.  Background  . . . . . . . . . . . . . . . . . . . . . . .   7
     2.2.  Update to RFC 3339  . . . . . . . . . . . . . . . . . . .   7
     2.3.  Notes . . . . . . . . . . . . . . . . . . . . . . . . . .   8
   3.  Internet Extended Date/Time format (IXDTF)  . . . . . . . . .   8
     3.1.  Format of Extended Information  . . . . . . . . . . . . .   8
     3.2.  Registering Keys for Extended Information Tags  . . . . .   9
     3.3.  Optional Generation, Elective vs. Critical Consumption  .   9
     3.4.  Inconsistent time-offset/Time-Zone Information  . . . . .  11
   4.  Syntax Extensions to RFC 3339 . . . . . . . . . . . . . . . .  12
     4.1.  ABNF  . . . . . . . . . . . . . . . . . . . . . . . . . .  12
     4.2.  Examples  . . . . . . . . . . . . . . . . . . . . . . . .  14
   5.  The u-ca Suffix Key: Calendar Awareness . . . . . . . . . . .  14
   6.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  15
   7.  Security Considerations . . . . . . . . . . . . . . . . . . .  15
     7.1.  Excessive Disclosure  . . . . . . . . . . . . . . . . . .  16
     7.2.  Data Format Implementation Vulnerabilities  . . . . . . .  16

Sharma & Bormann          Expires 25 April 2024                 [Page 2]
Internet-Draft   Internet Extended Date/Time Fmt (IXDTF)    October 2023

     7.3.  Operating with Inconsistent Data  . . . . . . . . . . . .  16
   8.  References  . . . . . . . . . . . . . . . . . . . . . . . . .  16
     8.1.  Normative References  . . . . . . . . . . . . . . . . . .  16
     8.2.  Informative References  . . . . . . . . . . . . . . . . .  17
   Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . . .  19
   Contributors  . . . . . . . . . . . . . . . . . . . . . . . . . .  19
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  19

1.  Introduction

   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.  [ISO8601-1:2019] standardizes a
   widely-adopted timestamp format, an earlier version of which
   [ISO8601:1988] formed the basis of the Internet Date/Time Format
   [RFC3339].  However, this format allows timestamps to contain only
   very little additional relevant information.  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 a pressing issue for applications that handle each such
   instant in time with an associated time zone name, in order to take
   into account events such as daylight saving time transitions.  Many
   of these applications attach the time zone 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 in which it should be represented.

1.1.  Scope

   This document defines an extension syntax for timestamps as specified
   in [RFC3339] that has the following properties:

   *  The extension suffix is completely optional, making existing
      [RFC3339] timestamps compatible with this format.

   *  The format is compatible with the pre-existing popular syntax for
      attaching time zone names to timestamps [JAVAZDT].

   *  The format provides a generalized way to attach additional
      information to the timestamp.

   We refer to this format as the Internet Extended Date/Time Format
   (IXDTF).

Sharma & Bormann          Expires 25 April 2024                 [Page 3]
Internet-Draft   Internet Extended Date/Time Fmt (IXDTF)    October 2023

   This document does not address extensions to the format where the
   semantic result is no longer a fixed timestamp that is referenced to
   a (past or future) UTC time.  For instance, it does not address:

   *  Future time given as a local time in some specified time zone,
      where changes to the definition of that time zone (such as a
      political decision to enact or rescind daylight saving time)
      affect the instant in time represented by the timestamp.

   *  "Floating time", i.e., a local time without information describing
      the UTC offset or time zone in which it should be interpreted.

   *  The use of timescales different from UTC, such as International
      Atomic Time (TAI).

   However, additional information augmenting a fixed timestamp may be
   sufficient to detect an inconsistency between intention and the
   actual information in the timestamp, such as between the UTC offset
   and time zone name.  For instance, inconsistencies might arise
   because of:

   *  political decisions as discussed above, or

   *  updates to time zone definitions being applied at different times
      by timestamp producers and receivers, or

   *  errors in programs producing and consuming timestamps.

   While the information available in an IXDTF string is not generally
   sufficient to resolve an 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.

1.2.  Definitions

   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.

   UTC:  Coordinated Universal Time, as maintained since 1988 by the

Sharma & Bormann          Expires 25 April 2024                 [Page 4]
Internet-Draft   Internet Extended Date/Time Fmt (IXDTF)    October 2023

      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
      for which UTC was designed to be a useful successor.

   ABNF:  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.

   Internet Extended Date/Time Format (IXDTF):  The date/time format
      defined in Section 4 of this document.

   Timestamp:  An unambiguous representation of a particular instant in
      time.

   UTC Offset:  Difference between a given local time and UTC, usually
      given in negative or positive hours and minutes.  For example,
      local time in the city of New York, NY, USA, in the wintertime in
      2023, is 5 hours behind UTC, so its UTC offset is "-05:00".

   Z:  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".  (Definition from Section 2 of
      [RFC3339]; see [ICAO-PA] for the phonetic alphabet.)

   Time Zone:  A set of rules representing the relationship of local

Sharma & Bormann          Expires 25 April 2024                 [Page 5]
Internet-Draft   Internet Extended Date/Time Fmt (IXDTF)    October 2023

      time to UTC for a particular place or region.  Mathematically, a
      time zone can be thought of as a function that maps timestamps to
      UTC offsets.  Time zones can deterministically convert a timestamp
      to local time.  They can also be used in the reverse direction to
      convert local time to a timestamp, with the caveat that some local
      times may have zero or multiple possible timestamps due to nearby
      daylight saving time changes or other changes to the UTC offset of
      that time zone.  Unlike the UTC offset of a timestamp which makes
      no claims about the UTC offset of other related timestamps (and
      which is therefore unsuitable for performing local-time operations
      such as "one day later"), a time zone also defines how to derive
      new timestamps based on differences in local time.  For example,
      to calculate "one day later than this timestamp in San Francisco,
      California", a time zone is required because the UTC offset of
      local time in San Francisco can change from one day to the next.

   IANA Time Zone:  A named time zone that is included in the Time Zone
      Database (often called tz or zoneinfo) maintained by IANA
      [TZDB][BCP175].  Most IANA time zones are named for the largest
      city in a particular region that shares the same time zone rules,
      e.g., Europe/Paris or Asia/Tokyo [TZDB-NAMING].

      The rules defined for a named IANA time zone can change over time.
      The use of a named IANA time zone implies that the intent is for
      the rules to apply that are current at the time of interpretation:
      the additional information conveyed by using that time zone name
      is to change with any rule changes as recorded in the IANA time
      zone database.

   Offset Time Zone:  A time zone defined by a specific UTC offset, e.g.
      +08:45, and serialized using as its name the same numeric UTC
      offset format used in an RFC 3339 timestamp, for example:

      2022-07-08T00:14:07+08:45[+08:45]

      An offset in the suffix that does not repeat the offset of the
      timestamp is inconsistent (see Section 3.4).

      Although serialization with offset time zones is supported in this
      document for backwards compatibility with java.time.ZonedDateTime
      [JAVAZDT], use of offset time zones is strongly discouraged.  In
      particular, programs MUST NOT copy the UTC offset from a timestamp
      into an offset time zone in order to satisfy another program which
      requires a time zone suffix in its input.  Doing this will
      improperly assert that the UTC offset of timestamps in that
      location will never change, which can result in incorrect
      calculations in programs that add, subtract, or otherwise derive
      new timestamps from the one provided.  For example, 2020-01-

Sharma & Bormann          Expires 25 April 2024                 [Page 6]
Internet-Draft   Internet Extended Date/Time Fmt (IXDTF)    October 2023

      01T00:00+01:00[Europe/Paris] will let programs add six months to
      the timestamp while adjusting for Summer Time (daylight saving
      time).  But the same calculation applied to
      2020-01-01T00:00+01:00[+01:00] will produce an incorrect result
      that will be off by one hour in the timezone Europe/Paris.

   CLDR:  Common locale data repository [CLDR], a project of the Unicode
      Consortium to provide locale data to applications.

   For more information about timescales, see Appendix E of [RFC1305],
   Section 3 of [ISO8601:1988], and the appropriate ITU documents
   [ITU-R-TF.460-6].

2.  Updating RFC 3339

2.1.  Background

   Section 4.3 of [RFC3339] states that an offset given as Z or +00:00
   implies that "UTC is the preferred reference point for the specified
   time".  The offset -00:00 is provided as a way to express that "the
   time in UTC is known, but the offset to local time is unknown".

   This convention mirrors a similar convention for date/time
   information in email headers, described in Section 3.3 of [RFC5322]
   and introduced earlier in Section 3.3 of [RFC2822].  This email
   header convention is in actual use, while its adaptation into
   [RFC3339] was always compromised by the fact that [ISO8601:2000] and
   later versions do not actually allow -00:00.

   Implementations that needed to express the semantics of -00:00
   therefore tended to use Z instead.

2.2.  Update to RFC 3339

   This specification updates Section 4.3 of [RFC3339], aligning it with
   the actual practice of interpreting the offset Z to mean the same as-
   00:00: "the time in UTC is known, but the offset to local time is
   unknown".

   Section 4.3 of [RFC3339] is revised to read as follows:

Sharma & Bormann          Expires 25 April 2024                 [Page 7]
Internet-Draft   Internet Extended Date/Time Fmt (IXDTF)    October 2023

   |  If the time in UTC is known, but the offset to local time is
   |  unknown, this can be represented with an offset of "Z".  (The
   |  original version of this specification provided "-00:00" for this
   |  purpose, which is not allowed by [ISO8601:2000] and therefore is
   |  less interoperable; Section 3.3 of [RFC5322] describes a related
   |  convention for email which does not have this problem).  This
   |  differs semantically from an offset of "+00:00", which implies
   |  that UTC is the preferred reference point for the specified time.

2.3.  Notes

   Note that the semantics of the local offset +00:00 is not updated;
   this retains the implication that UTC is the preferred reference
   point for the specified time.

   Note also that the fact that [ISO8601:2000] and later do not allow
   -00:00 as a local offset reduces the level of interoperability that
   can be achieved in using this feature; the present specification
   however does not formally deprecate this syntax.  With the update to
   RFC 3339, the local offset Z should now be used in its place.

3.  Internet Extended Date/Time format (IXDTF)

   This section discusses desirable qualities of formats for the
   timestamp extension suffix and defines the IXDTF format, which
   extends [RFC3339] for use in Internet protocols.

3.1.  Format of Extended Information

   The format allows applications to specify additional important
   information in addition to a bare [RFC3339] timestamp.

   This is done by defining _tags_, each with a _key_ and a _value_
   separated by an equals sign.  The value of a tag can be one or more
   items delimited by hyphen/minus signs.

   Applications can build an informative timestamp _suffix_ using any
   number of these tags.

   Keys are lower-case only.  Values are case-sensitive unless otherwise
   specified.

   See Section 3.3 for the handling of inconsistent information in a
   suffix.

Sharma & Bormann          Expires 25 April 2024                 [Page 8]
Internet-Draft   Internet Extended Date/Time Fmt (IXDTF)    October 2023

3.2.  Registering Keys for Extended Information Tags

   Suffix tag keys are registered by supplying the information specified
   in this section.  This information is modeled after that specified
   for the media type registry [RFC6838]; if in doubt, the provisions of
   this registry should be applied analogously.

   Key Identifier:  The key (conforming to suffix-key in Section 4.1)

   Registration status:  "Provisional" or "Permanent"

   Description:  A very brief description of the key.

   Change controller:  Who is in control of evolving the specification
      governing values for this key.  This information can include email
      addresses of contact points and discussion lists, and references
      to relevant web pages (URLs).

   Reference:  A reference.  For permanent tag keys, this includes a
      full specification.  For provisional tag keys, there is an
      expectation that some information is available even if that does
      not amount to a full specification; in this case, the registrant
      is expected to improve this information over time.

   Key names that start with an underscore are intended for experiments
   in controlled environments and cannot be registered; such keys MUST
   NOT be used for interchange and MUST be rejected by implementations
   not specifically configured to take part in such an experiment.  See
   [BCP178] for a discussion about the danger of experimental keys
   leaking out to general production and why that must be prevented.

3.3.  Optional Generation, Elective vs. Critical Consumption

   For the IXDTF format, suffix tags are always _optional_: They can be
   added or left out as desired by the generator of the string.  (An
   application might require the presence of specific suffix tags,
   though.)

   Without further indication, suffix tags are also _elective_: The
   recipient is free to ignore any suffix tag included in an IXDTF
   string.  Reasons might include that the recipient does not implement
   (or know about) the specific suffix key, or that it does recognize
   the key but cannot act on the value provided.

Sharma & Bormann          Expires 25 April 2024                 [Page 9]
Internet-Draft   Internet Extended Date/Time Fmt (IXDTF)    October 2023

   A suffix tag may also indicate that it is _critical_: The recipient
   is advised that it MUST NOT act on the Internet Extended Date/Time
   Format (IXDTF) string unless it can process the suffix tag as
   specified.  A critical suffix tag is indicated by following its
   opening bracket with an exclamation mark (see critical-flag in
   Section 4.1).

   For example, IXDTF strings such as:

   2022-07-08T00:14:07+01:00[Europe/Paris]

   are internally inconsistent (see Section 3.4), because Europe/Paris
   did not use a time zone offset of +01:00 in July 2022.  The time zone
   hint given in the suffix tag is elective, though, so the recipient is
   not required to act on the inconsistency; it can treat the Internet
   Date/Time Format string as if it were:

   2022-07-08T00:14:07+01:00

      |  Note that as per Section 2 (see also Section 3.4), the IXDTF
      |  string:
      |  
      |     2022-07-08T00:14:07Z[Europe/Paris]
      |  
      |  does not exhibit such an inconsistency, as the local offset of
      |  Z does not imply a specific preferred time zone of
      |  interpretation.  Using the Time Zone Database rules for Europe/
      |  Paris in the summer of 2022, it is equivalent to:
      |  
      |     2022-07-08T02:14:07+02:00[Europe/Paris]

   Similarly, an unknown suffix may be entirely ignored:

   2022-07-08T00:14:07+01:00[knort=blargel]

   (assuming that the recipient does not understand the suffix key
   knort).

   In contrast to this elective use of a suffix tag,

   2022-07-08T00:14:07+01:00[!Europe/Paris]
   2022-07-08T00:14:07Z[!u-ca=chinese][u-ca=japanese]
   2022-07-08T00:14:07Z[u-ca=chinese][!u-ca=japanese]
   2022-07-08T00:14:07Z[!knort=blargel]

Sharma & Bormann          Expires 25 April 2024                [Page 10]
Internet-Draft   Internet Extended Date/Time Fmt (IXDTF)    October 2023

   each have an internal inconsistency or an unrecognized suffix key/
   value that are marked as critical, so a recipient MUST treat these
   IXDTF strings as erroneous.  This means that the application MUST
   reject the data, or perform some other error handling, such as asking
   the user how to resolve the inconsistency (see Section 3.4).

   Note that applications MAY also perform additional processing on
   inconsistent or unrecognized elective suffix tags, such as asking the
   user how to resolve the inconsistency.  While they are not required
   to do so with elective suffix tags, they are required to reject or
   perform some other error handling when encountering inconsistent or
   unrecognized suffix tags marked as critical.

   An application that encounters duplicate use of a suffix key in
   elective suffixes and does not want to perform additional processing
   on this inconsistency MUST choose the first suffix that has that key,
   i.e.,

   2022-07-08T00:14:07Z[u-ca=chinese][u-ca=japanese]
   2022-07-08T00:14:07Z[u-ca=chinese]

   are then treated the same.

3.4.  Inconsistent time-offset/Time-Zone Information

   An RFC 3339 timestamp can contain a time-offset value that indicates
   the offset between local time and UTC (see Section 4 of [RFC3339],
   noting that Section 2 of the present specification updates
   Section 4.3 of [RFC3339]).

   The information given in such a time-offset value can be inconsistent
   with the information provided in a time zone suffix for an IXDTF
   timestamp.

   For example, a calendar application could store an IXDTF string
   representing a far-future meeting in a particular time zone.  If that
   time zone's definition is subsequently changed to abolish daylight
   saving time, IXDTF strings that were originally consistent may now be
   inconsistent.

   In case of inconsistent time-offset and time zone suffix, if the
   critical flag is used on the time zone suffix, an application MUST
   act on the inconsistency.  If the critical flag is not used, it MAY
   act on the inconsistency.  Acting on the inconsistency may involve
   rejecting the timestamp, or resolving the inconsistency via
   additional information such as user input and/or programmed behavior.

Sharma & Bormann          Expires 25 April 2024                [Page 11]
Internet-Draft   Internet Extended Date/Time Fmt (IXDTF)    October 2023

   For example, the IXDTF timestamps in Figure 1 represent 00:14:07 UTC,
   indicating a local time with a time-offset of +00:00.  However,
   because Europe/London used offset +01:00 in July 2022, the timestamps
   are inconsistent in Figure 1, where the first case is one where the
   application MUST act on the inconsistency (the time zone suffix is
   marked critical), and the second case is one where it MAY act on it
   (time zone suffix is elective).

   2022-07-08T00:14:07+00:00[!Europe/London]
   2022-07-08T00:14:07+00:00[Europe/London]

                  Figure 1: Inconsistent IXDTF timestamps

   As per Section 4.3 of [RFC3339] as updated by Section 2, IXDTF
   timestamps may also forego indicating local time information in their
   [RFC3339] part by using Z instead of a numeric time zone offset.  The
   IXDTF timestamps in Figure 2 (which represent the same instant in
   time as the strings in Figure 1) are not inconsistent because they do
   not assert any particular local time nor local offset in their
   [RFC3339] part.  Instead, applications that receive these strings can
   calculate the local offset and local time using the rules of the time
   zone suffix, such as Europe/London in the example in Figure 2, which
   like Figure 1 has a case with a time zone suffix marked critical,
   i.e., the intention is that the application must understand the time
   zone information, and one marked elective, which then only is
   provided as additional information.

   2022-07-08T00:14:07Z[!Europe/London]
   2022-07-08T00:14:07Z[Europe/London]

               Figure 2: No inconsistency in IXDTF timestamps

   Note that -00:00 may be used instead of Z, because they have the same
   meaning according to Section 2, but -00:00 is not allowed by
   [ISO8601:2000] and later so Z is preferred.

4.  Syntax Extensions to RFC 3339

4.1.  ABNF

   The following rules extend the ABNF syntax defined in [RFC3339] in
   order to allow the inclusion of an optional suffix.

   The Internet Extended Date/Time Format (IXDTF) is described by the
   rule date-time-ext.

   date-time and time-numoffset are imported from Section 5.6 of
   [RFC3339], ALPHA and DIGIT from Appendix B.1 of [RFC5234].

Sharma & Bormann          Expires 25 April 2024                [Page 12]
Internet-Draft   Internet Extended Date/Time Fmt (IXDTF)    October 2023

   time-zone-initial = ALPHA / "." / "_"
   time-zone-char    = time-zone-initial / DIGIT / "-" / "+"
   time-zone-part    = time-zone-initial *time-zone-char
                       ; but not "." or ".."
   time-zone-name    = time-zone-part *("/" time-zone-part)
   time-zone         = "[" critical-flag
                           time-zone-name / time-numoffset "]"

   key-initial       = lcalpha / "_"
   key-char          = key-initial / DIGIT / "-"
   suffix-key        = key-initial *key-char

   suffix-value      = 1*alphanum
   suffix-values     = suffix-value *("-" suffix-value)
   suffix-tag        = "[" critical-flag
                           suffix-key "=" suffix-values "]"
   suffix            = [time-zone] *suffix-tag

   date-time-ext     = date-time suffix

   critical-flag     = [ "!" ]

   alphanum          = ALPHA / DIGIT
   lcalpha           = %x61-7A

              Figure 3: ABNF grammar of extensions to RFC 3339

   Note that a time-zone is syntactically similar to a suffix-tag, but
   does not include an equals sign.  This special case is only available
   for time zone tags.

   The ABNF definition of time-zone-part matches "." and "..", which
   however both are explicitly excluded (see also comment on time-zone-
   part).

   time-zone-name is intended to be the name of an IANA Time Zone.  As
   generator and recipient may be using different revisions of the Time
   Zone Database, recipients may not be aware of such an IANA Time Zone
   name and should treat such a situation as any other inconsistency.

      |  Note: At the time of writing, the length of each time-zone-part
      |  is limited to a maximum of 14 characters by the rules in
      |  [TZDB-NAMING].  One platform is known to enforce this limit, an
      |  entry in a timezone database on another platform is known to
      |  exceed this limit.  As the time-zone-name will ultimately have
      |  to be looked up in the database, which therefore has control
      |  over the length, the time-zone-part production in Figure 3 is
      |  deliberately permissive.

Sharma & Bormann          Expires 25 April 2024                [Page 13]
Internet-Draft   Internet Extended Date/Time Fmt (IXDTF)    October 2023

4.2.  Examples

   Here are some examples of Internet Extended Date/Time Format (IXDTF).

   1996-12-19T16:39:57-08:00

             Figure 4: RFC 3339 date-time with time zone offset

   Figure 4 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 5: Adding a time zone name

   Figure 5 represents the exact same instant in time as the previous
   example but additionally specifies the human time zone associated
   with it ("Pacific Time") for time-zone-aware applications to take
   into account.

   1996-12-19T16:39:57-08:00[America/Los_Angeles][u-ca=hebrew]

                Figure 6: Projecting to the Hebrew calendar

   Figure 6 represents the exact same instant in time, but it informs
   calendar-aware applications (see Section 5) that they should project
   it to the Hebrew calendar.

   1996-12-19T16:39:57-08:00[_foo=bar][_baz=bat]

                     Figure 7: Adding experimental tags

   Figure 7, based on Figure 4, utilizes keys identified as experimental
   by a leading underscore to declare two additional pieces of
   information in the suffix; these can be interpreted by
   implementations that take part in the controlled experiment making
   use of these tag keys.

5.  The u-ca Suffix Key: Calendar Awareness

   Out of the possible suffix keys, the suffix key u-ca is allocated to
   indicate the calendar in which the date/time is preferably presented.

   A calendar is a set of rules defining how dates are counted and
   consumed by implementations.  The set of suffix values allowed for
   this suffix key is the set of values defined for the Unicode Calendar

Sharma & Bormann          Expires 25 April 2024                [Page 14]
Internet-Draft   Internet Extended Date/Time Fmt (IXDTF)    October 2023

   Identifier [TR35].  A resource that has been built to provide links
   into the most recent stable and development [CLDR] information about
   that is provided by [CLDR-LINKS].

6.  IANA Considerations

   // RFC Editor: please replace RFCthis with the RFC number of this RFC
   // and remove this note.

   IANA is requested to establish a registry called "Timestamp Suffix
   Tag Keys" in a new registry group "Internet Date/Time Format".  Each
   entry in the registry shall consist of the information described in
   Section 3.2.  Initial contents of the registry are specified in
   Table 1.

    +============+==============+==============+============+=========+
    | Key        | Registration | Description: | Change     |Reference|
    | Identifier | status       |              | controller |         |
    +============+==============+==============+============+=========+
    | u-ca       | Permanent    | Preferred    | IESG       |Section 5|
    |            |              | Calendar for |            |of       |
    |            |              | Presentation |            |RFCthis  |
    +------------+--------------+--------------+------------+---------+

       Table 1: Initial Content of Timestamp Suffix Tag Keys registry

   The registration policy [BCP26] is "Specification Required" for
   permanent entries, and "Expert Review" for provisional ones.  In the
   second case, the expert is instructed to ascertain that a basic
   specification does exist, even if not complete or published yet.

   The experts also are instructed to be frugal in the allocation of key
   identifiers that are suggestive of generally applicable semantics,
   keeping them in reserve for suffix keys that are likely to enjoy wide
   use and can make good use of the key identifier's conciseness.  If
   the experts become aware of key identifiers that are deployed and in
   use, they may also initiate a registration on their own if they deem
   such a registration can avert potential future collisions.

7.  Security Considerations

Sharma & Bormann          Expires 25 April 2024                [Page 15]
Internet-Draft   Internet Extended Date/Time Fmt (IXDTF)    October 2023

7.1.  Excessive Disclosure

   The ability to include various pieces of ancillary information with a
   timestamp might lead to excessive disclosure.  An example for
   possibly excessive disclosure is given in Section 7 of [RFC3339].
   Similarly, divulging information about the calendar system or the
   language of choice may provide more information about the originator
   of a timestamp than the data minimization principle would permit
   [DATA-MINIMIZATION].  More generally speaking, generators of IXDTF
   timestamps need to consider whether information to be added to the
   timestamp is appropriate to divulge to the recipients of this
   information, and need to err on the side of minimizing such
   disclosure if the set of recipients is not under control of the
   originator.

7.2.  Data Format Implementation Vulnerabilities

   As usual when extending the syntax of a data format, this can lead to
   new vulnerabilities in implementations parsing and processing the
   format.  No considerations are known for the IXDTF syntax that would
   pose concerns that are out of the ordinary.

7.3.  Operating with Inconsistent Data

   Information provided in the various parts of an IXDTF string may be
   inconsistent in interesting ways, both with the extensions defined in
   this specification (see for instance Section 3.4) and with future
   extensions still to be defined.  Where consistent interpretation
   between multiple actors is required for security purposes (e.g.,
   where timestamps are embedded as parameters in access control
   information), only those extensions can be employed that have a well-
   understood and shared resolution of such inconsistent data.

8.  References

8.1.  Normative References

   [BCP175]   Lear, E. and P. Eggert, "Procedures for Maintaining the
              Time Zone Database", BCP 175, RFC 6557,
              DOI 10.17487/RFC6557, February 2012,
              <https://www.rfc-editor.org/rfc/rfc6557>.

   [BCP178]   Saint-Andre, P., Crocker, D., and M. Nottingham,
              "Deprecating the "X-" Prefix and Similar Constructs in
              Application Protocols", BCP 178, RFC 6648,
              DOI 10.17487/RFC6648, June 2012,
              <https://www.rfc-editor.org/rfc/rfc6648>.

Sharma & Bormann          Expires 25 April 2024                [Page 16]
Internet-Draft   Internet Extended Date/Time Fmt (IXDTF)    October 2023

   [BCP26]    Cotton, M., Leiba, B., and T. Narten, "Guidelines for
              Writing an IANA Considerations Section in RFCs", BCP 26,
              RFC 8126, DOI 10.17487/RFC8126, June 2017,
              <https://www.rfc-editor.org/rfc/rfc8126>.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997,
              <https://www.rfc-editor.org/rfc/rfc2119>.

   [RFC3339]  Klyne, G. and C. Newman, "Date and Time on the Internet:
              Timestamps", RFC 3339, DOI 10.17487/RFC3339, July 2002,
              <https://www.rfc-editor.org/rfc/rfc3339>.

   [RFC5234]  Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
              Specifications: ABNF", STD 68, RFC 5234,
              DOI 10.17487/RFC5234, January 2008,
              <https://www.rfc-editor.org/rfc/rfc5234>.

   [RFC6838]  Freed, N., Klensin, J., and T. Hansen, "Media Type
              Specifications and Registration Procedures", BCP 13,
              RFC 6838, DOI 10.17487/RFC6838, January 2013,
              <https://www.rfc-editor.org/rfc/rfc6838>.

   [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
              2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
              May 2017, <https://www.rfc-editor.org/rfc/rfc8174>.

8.2.  Informative References

   [CLDR]     "Unicode CLDR Project", <https://cldr.unicode.org>.

   [CLDR-LINKS]
              Unicode CLDR, "Stable Links Info",
              <https://cldr.unicode.org/stable-links-info>.

   [DATA-MINIMIZATION]
              Arkko, J., "Emphasizing data minimization among protocol
              participants", Work in Progress, Internet-Draft, draft-
              arkko-iab-data-minimization-principle-05, 10 July 2023,
              <https://datatracker.ietf.org/doc/html/draft-arkko-iab-
              data-minimization-principle-05>.

Sharma & Bormann          Expires 25 April 2024                [Page 17]
Internet-Draft   Internet Extended Date/Time Fmt (IXDTF)    October 2023

   [ICAO-PA]  International Civil Aviation Organization, "Annex 10 to
              the Convention on International Civil Aviation:
              Aeronautical Telecommunications; Volume II Communication
              Procedures including those with PANS status (7th ed.)",
              July 2016, <https://store.icao.int/annex-10-aeronautical-
              telecommunications-volume-ii-communication-procedures-
              including-those-with-pans-status>.

   [IERS]     "International Earth Rotation Service Bulletins",
              <https://www.iers.org/IERS/EN/Publications/Bulletins/
              bulletins.html>.

   [ISO8601-1:2019]
              ISO, "Date and time — Representations for information
              interchange — Part 1: Basic rules", ISO 8601-1:2019,
              February 2019, <https://www.iso.org/standard/70907.html>.

   [ISO8601:1988]
              ISO, "Data elements and interchange formats — Information
              interchange — Representation of dates and times",
              ISO 8601:1988, June 1988,
              <https://www.iso.org/standard/15903.html>.  Also available
              from <https://nvlpubs.nist.gov/nistpubs/Legacy/FIPS/
              fipspub4-1-1991.pdf
              (https://nvlpubs.nist.gov/nistpubs/Legacy/FIPS/
              fipspub4-1-1991.pdf)>.

   [ISO8601:2000]
              ISO, "Data elements and interchange formats — Information
              interchange — Representation of dates and times",
              ISO 8601:2000, December 2000,
              <https://www.iso.org/standard/26780.html>.

   [ITU-R-TF.460-6]
              "ITU-R TF.460-6. Standard-frequency and time-signal
              emissions", February 2002,
              <https://www.itu.int/rec/R-REC-TF.460/en>.

   [JAVAZDT]  "Java SE 8, java.time.format, DateTimeFormatter:
              ISO_ZONED_DATE_TIME",
              <https://docs.oracle.com/javase/8/docs/api/java/time/
              format/DateTimeFormatter.html#ISO_ZONED_DATE_TIME>.

   [RFC1305]  Mills, D., "Network Time Protocol (Version 3)
              Specification, Implementation and Analysis", RFC 1305,
              DOI 10.17487/RFC1305, March 1992,
              <https://www.rfc-editor.org/rfc/rfc1305>.

Sharma & Bormann          Expires 25 April 2024                [Page 18]
Internet-Draft   Internet Extended Date/Time Fmt (IXDTF)    October 2023

   [RFC2822]  Resnick, P., Ed., "Internet Message Format", RFC 2822,
              DOI 10.17487/RFC2822, April 2001,
              <https://www.rfc-editor.org/rfc/rfc2822>.

   [RFC5322]  Resnick, P., Ed., "Internet Message Format", RFC 5322,
              DOI 10.17487/RFC5322, October 2008,
              <https://www.rfc-editor.org/rfc/rfc5322>.

   [TR35]     "Unicode Technical Standard #35: Unicode Locale Data
              Markup Language (LDML)", <https://www.unicode.org/reports/
              tr35/#UnicodeCalendarIdentifier>.

   [TZDB]     "Sources for time zone and daylight saving time data",
              <https://data.iana.org/time-zones/tz-link.html>.

   [TZDB-NAMING]
              "Theory and pragmatics of the tz code and data",
              <https://data.iana.org/time-zones/theory.html>.

Acknowledgements

   Richard Gibson and Justin Grant provided editorial improvements.  The
   authors would like to thank Francesca Palombini for her AD review.

Contributors

   Justin Grant
   Email: justingrant.ietf.public@gmail.com

Authors' Addresses

   Ujjwal Sharma
   Igalia, S.L.
   Bugallal Marchesi, 22, 1º
   15008 A Coruña
   Spain
   Email: ryzokuken@igalia.com

   Carsten Bormann
   Universität Bremen TZI
   Postfach 330440
   D-28359 Bremen
   Germany
   Phone: +49-421-218-63921
   Email: cabo@tzi.org

Sharma & Bormann          Expires 25 April 2024                [Page 19]