1.1.Scope

[RFC3339] defines a syntax for timestamps to represent date and time in the Internet. The present document defines an extension syntax that achieves 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 attachingtime zone names to timestamps[JAVAZDT].¶

• The format provides a generalized way to attach additionalinformation to the timestamp.¶

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

This document does not address extensions to the format where thesemantic 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, wherechanges to the definition of that time zone (such as a politicaldecision to enact or rescind daylight saving time) affect theinstant in time represented by the timestamp;¶

• "floating time", i.e., a local time without information describingthe UTC offset or time zone in which it should be interpreted; or¶

• the use of timescales different from UTC, such as International AtomicTime (TAI).¶

However, additional information augmenting a fixed timestamp may besufficient to detect an inconsistency between the intention and the actualinformation in the timestamp, such as between the UTC offset and time zonename.For instance, inconsistencies might arise because of:¶

• political decisions, as discussed above,¶

• updates to time zone definitions being applied at different timesby 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 resolvean inconsistency, it may be used to initiate some out-of-bandprocessing to obtain sufficient information for such a resolution.¶

In order to address some of the requirements implied here,related specifications in the future might define syntax and semantics of stringssimilar to those described in[RFC3339].Note that the extension syntax defined in the present document isdesigned in such a way that it can be useful for such specificationsas 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 BureauInternational des Poids et Mesures (BIPM) in conjunction with leapseconds as announced by the International Earth Rotation andReference Systems Service[IERS].From 1972 through 1987, UTC was maintained entirely by the BureauInternational de l'Heure (BIH).Before 1972, UTC was not generally recognized, and civil time wasdetermined by individual jurisdictions using different techniquesfor attempting to follow Universal Time based on measuring therotation of the earth.¶

UTC is often mistakenly referred to as GMT (Greenwich Mean Time), an earlier timescalefor which UTC was designed to be a useful successor.¶

ABNF:

Augmented Backus-Naur Form, a format used to represent permissiblestrings in a protocol or language, as defined in[RFC5234].The rules defined inAppendix B of [RFC5234] are imported implicitly.¶

IXDTF:

Internet Extended Date/Time Format, the date/time format defined inSection 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 innegative or positive hours and minutes. For example, local time inthe city of New York, NY, USA in the wintertime in 2023 was 5 hoursbehind UTC, so its UTC offset was-05:00.¶

Z:

A suffix that, when applied to a time, denotes a UTC offset of00:00; often pronounced "Zulu" from the ICAO phonetic alphabetrepresentation of the letter "Z".(The definition is fromSection 2 of [RFC3339]; see the International Civil Aviation Organization (ICAO) document[ICAO-PA] for thephonetic alphabet mentioned.)¶

Time Zone:

A set of rules representing the relationship of local time to UTCfor a particular place or region. Mathematically, a time zone canbe 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 timeto a timestamp, with the caveat that some local times may have zeroor multiple possible timestamps due to nearby daylight saving timechanges or other changes to the UTC offset of that time zone.Unlike the UTC offset of a timestamp, which makes no claims aboutthe UTC offset of other related timestamps (and which is thereforeunsuitable for performing local-time operations, such as"one day later"), a time zone also defines how to derive newtimestamps based on differences in local time.For example, to calculate "one day later than thistimestamp in San Francisco, California", a time zone is required because theUTC offset of local time in San Francisco can change from one dayto the next.¶

IANA Time Zone:

A named time zone that is included in the Time Zone Database (oftencalledtz orzoneinfo) maintained by IANA[TZDB][BCP175].Most IANA Time Zonesare named for the largest city in a particular region that sharesthe same time zone rules, e.g.,Europe/Paris orAsia/Tokyo[TZDB-NAMING].¶

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

Offset Time Zone:

A time zone defined by a specific UTC offset, e.g.,+08:45, andserialized using as its name the same numeric UTC offset format used in an[RFC3339]timestamp, for example:¶

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

¶

An offset in the suffix that does not repeat the offset of thetimestamp is inconsistent (seeSection 3.4).¶

Although serialization with offset time zones issupported in this document for backwards compatibility withjava.time.ZonedDateTime[JAVAZDT], use of offset time zones isstrongly discouraged.In particular, programsMUST NOT copy the UTCoffset from a timestamp into an offset time zone in order to satisfyanother program that requires a time zone suffix in its input.Doing this will improperly assert that the UTC offset of timestampsin that location will never change, which can result in incorrectcalculations in programs that add, subtract, or otherwise derive newtimestamps from the one provided. For example,2020-01-01T00:00+01:00[Europe/Paris] will let programs add sixmonths to the timestamp while adjusting for summer time (daylight saving time).However, the same calculation applied to2020-01-01T00:00+01:00[+01:00]will produce an incorrect result that will be off by one hour in thetime zoneEurope/Paris.¶

CLDR:

Common Locale Data Repository[CLDR], a project of the UnicodeConsortium to provide locale data to applications.¶

For more information about timescales, seeAppendix E of [RFC1305],Section 3 of[ISO8601:1988], and the appropriate ITU documents[ITU-R-TF.460-6]. (Note:[RFC1305] was obsoleted by[RFC5905],which no longer contains the AppendixE referenced here.)¶

2.1.Background

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

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

Implementations that needed to express the semantics of-00:00therefore tended to useZ instead.¶

2.2.Update to RFC 3339

This specification updatesSection 4.3 of [RFC3339], aligning it with the actualpractice of interpreting the offsetZ 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:¶

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 pointfor the specified time.¶

Also note that the fact that[ISO8601:2000] and later do not allow-00:00 as alocal offset reduces the level of interoperability that can beachieved in using this feature; however, the present specification doesnot formally deprecate this syntax.With the update to[RFC3339], the local offsetZ should now be used in itsplace.¶

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 definingtags, each with akey and avalueseparated by an equals sign. The value of a tag can be one or moreitems delimited by hyphen/minus signs.¶

Applications can build an informative timestampsuffix using any number of these tags.¶

Keys are lowercase only. Values are case-sensitive unless otherwise specified.¶

SeeSection 3.3 for the handling of inconsistent informationin a suffix.¶

3.2.Registering Keys for Extended Information Tags

Suffix tag keys are registered by supplying the informationspecified in this section. This information is modeled after thatspecified for the "Media Types" registry[RFC6838]; if in doubt, the provisions of this registry should be applied analogously.¶

Key Identifier:

The key (conforming tosuffix-key inSection 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 forthis key. This information can include email addresses of contactpoints, 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 someinformation is available even if that does not amount to a fullspecification; in this case, the registrant is expected to improve thisinformation over time.¶

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

3.3.Optional Generation and Elective vs. Critical Consumption

For the IXDTF format, suffix tags are alwaysoptional. Theycan be added or left out as desired by the generator of the string.(An application might require the presenceof specific suffix tags, though.)¶

Without further indication, suffix tags are alsoelective.The recipient is free to ignore any suffix tag included in an IXDTFstring.Reasons might include that the recipient doesnot implement (or know about) the specific suffix key or that it doesrecognize the key but cannot act on the value provided.¶

A suffix tag may also indicate that it iscritical: The recipient isadvised that itMUST NOT act on the IXDTF stringunless it can process the suffix tag as specified. A critical suffixtag is indicated by following its opening bracket with an exclamationmark (seecritical-flag inSection 4.1).¶

For example, IXDTF strings such as:¶

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

are internally inconsistent (seeSection 3.4), becauseEurope/Paris did notuse a time zone offset of+01:00 in July 2022.However, the time zone hint given in the suffix tag is elective, so the recipient is notrequired to act on the inconsistency; it can treat the InternetDate/Time Format string as if it were:¶

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

Note that, as perSection 2 (see alsoSection 3.4), the IXDTF string:¶

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

does not exhibit such an inconsistency, as the local offset ofZdoes not imply a specific preferred time zone of interpretation.Using the Time Zone Database rules forEurope/Paris inthe 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 keyknort).¶

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]

each have an internal inconsistency or an unrecognized suffix key/valuethat is marked as critical, so a recipientMUST treat these IXDTFstrings as erroneous.This means that the applicationMUST reject the data or perform someother error handling, such as asking the user how to resolve theinconsistency (seeSection 3.4).¶

Note that applicationsMAY also perform additional processing oninconsistent or unrecognized elective suffix tags, such as asking theuser how to resolve the inconsistency.While they are not required to do so with elective suffix tags, they arerequired to reject or perform some other error handling whenencountering inconsistent or unrecognized suffix tags marked ascritical.¶

An application that encounters duplicate use of a suffix key inelective suffixes and does not want to perform additional processingon this inconsistencyMUST choose the first suffix that has that key,that is,¶

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.Inconsistenttime-offset and Time Zone Information

An[RFC3339] timestamp can contain atime-offset value that indicatesthe offset between local time and UTC (seeSection 4 of [RFC3339],noting thatSection 2 of the present specification updatesSection 4.3 of [RFC3339]).¶

The information given in such atime-offset value can beinconsistent with the information provided in a time zone suffix for anIXDTF timestamp.¶

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

In case of an inconsistency betweentime-offset and time zone suffix, if thecritical flag is used on the time zone suffix, an applicationMUST acton the inconsistency.If the critical flag is not used, itMAY act on the inconsistency.Acting on the inconsistency may involve rejecting the timestamp orresolving the inconsistency via additional information, such as user inputand/or programmed behavior.¶

For example, the IXDTF timestamps inFigure 1 represent00:14:07 UTC, indicating a local time with atime-offset of+00:00.However, becauseEurope/London used offset+01:00 in July 2022, thetimestamps are inconsistent, where the firstcase is one for which the applicationMUST act on the inconsistency (thetime zone suffix is marked critical) and the second case is one for whichitMAY act on the inconsistency (the time zone suffix is elective).¶

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

As perSection 4.3 of [RFC3339] as updated bySection 2, IXDTFtimestamps may also forego indicating local time information in their[RFC3339] part by usingZ instead of a numeric time zone offset.The IXDTF timestamps inFigure 2 (which represent the sameinstant in time as the strings inFigure 1) are notinconsistent because they do not assert any particular local time norlocal offset in their[RFC3339] part.Instead, applications that receive these strings can calculate thelocal offset and local time using the rules of the time zone suffix,such asEurope/London in the example inFigure 2, whichlikeFigure 1 has a case with a time zone suffix markedcritical (i.e., the intention is that the application must understandthe time zone information) and one marked elective, which then only isprovided as additional information.¶

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

Note that-00:00 may be used instead ofZ because they have thesame meaning according toSection 2, but-00:00 is not allowed by[ISO8601:2000] and later soZ is preferred.¶

4.1.ABNF

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

The Internet Extended Date/Time Format (IXDTF) is described by theruledate-time-ext.¶

date-time andtime-numoffset are imported fromSection 5.6 of [RFC3339], andALPHA andDIGIT are imported fromAppendix B.1 of [RFC5234].¶

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-charsuffix-value      = 1*alphanumsuffix-values     = suffix-value *("-" suffix-value)suffix-tag        = "[" critical-flag                        suffix-key "=" suffix-values "]"suffix            = [time-zone] *suffix-tagdate-time-ext     = date-time suffixcritical-flag     = [ "!" ]alphanum          = ALPHA / DIGITlcalpha           = %x61-7A

Note that atime-zone is syntactically similar to asuffix-tagbut does not include an equals sign.This special case is only available for time zone tags.¶

The ABNF definition oftime-zone-part matches "." and "..", whichare both explicitly excluded (see the note below ontime-zone-part).¶

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

Note: At the time of writing, the length of eachtime-zone-part islimited to a maximum of 14 characters by the rules in[TZDB-NAMING].One platform is known to enforce this limit, and a time zone nameon another platform is known to exceed this limit.As thetime-zone-name will ultimately have to be looked up in the localdatabase, which therefore has control over the length, thetime-zone-part production inFigure 3 is deliberately permissive.¶

4.2.Examples

This section contains some examples of Internet Extended Date/Time Format (IXDTF).¶

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

Figure 4 represents 39 minutes and 57 seconds after the 16th hour ofDecember 19, 1996, with an offset of-08:00 from UTC.Note that this is the same instant in time as1996-12-20T00:39:57Z, expressed in UTC.¶

1996-12-19T16:39:57-08:00[America/Los_Angeles]

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

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

Figure 6 represents the exact same instant in time, but it informs calendar-awareapplications (seeSection 5) that they should project it to the Hebrew calendar.¶

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

Figure 7, based onFigure 4, utilizes keysidentified as experimental by a leading underscore to declare two additional pieces ofinformation in the suffix; these can be interpreted by implementationsthat take part in the controlled experiment making use of these tag keys.¶

7.1.Excessive Disclosure

The ability to include various pieces of ancillary information with atimestamp might lead to excessive disclosure.An example for possibly excessive disclosure is given inSection 7 of [RFC3339].Similarly, divulging information about the calendar system or thelanguage of choice may provide more information about the originatorof a timestamp than the data minimization principle would permit[DATA-MINIMIZATION].More generally speaking, generators of IXDTF timestamps need toconsider whether information to be added to the timestamp isappropriate to divulge to the recipients of this information and needto err on the side of minimizing such disclosure if the set ofrecipients 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 tonew vulnerabilities in implementations parsing and processing theformat.No considerations are known for the IXDTF syntax that would poseconcerns 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 (for instance, seeSection 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 extensions that have a well-understood and shared resolution of such inconsistent data can be employed.¶