Date and Time on the Internet: Timestamps with Additional Information
updates
- rfc-3339 — Date and Time on the Internet: Timestamps
Extracted elements (22)
Offset time zones (e.g., [+08:45]) are supported for backwards compatibility with java.time.ZonedDateTime but are strongly discouraged. They incorrectly assert a permanently fixed UTC offset, causing wrong date arithmetic across DST boundaries. Named IANA Time Zones should be used instead.
RFC 9557 reinterprets the RFC 3339 offset 'Z' to mean 'the time in UTC is known, but the offset to local time is unknown' — the same semantics as -00:00 — rather than implying UTC is the preferred reference point. This change aligns with actual implementation practice: because ISO 8601:2000 does not allow -00:00, implementations had been using Z to express those semantics anyway.
The IXDTF suffix is completely optional, making all existing RFC 3339 timestamps valid IXDTF timestamps without modification. The format was also designed to be compatible with the pre-existing java.time.ZonedDateTime (ISO_ZONED_DATE_TIME) syntax for attaching time zone names, which was already widely adopted.
Producers and recipients may use different revisions of the IANA Time Zone Database. If a recipient does not recognize a time zone name in the suffix, it should treat this as any other inconsistency: ignore if elective, reject or error-handle if critical.
The use of Z instead of -00:00 is preferred because ISO 8601:2000 and later do not permit -00:00 as a local offset. Both carry the same updated semantics under this specification, but Z is more interoperable across implementations that validate against ISO 8601.
A suffix tag marked critical (critical-flag '!') requires that the recipient MUST NOT act on the IXDTF string unless it can process the tag as specified. The application MUST reject the data or perform explicit error handling, such as prompting the user to resolve the inconsistency.
Programs MUST NOT copy the UTC offset from a timestamp into an offset time zone suffix merely to satisfy a program requiring a time zone suffix. Doing so incorrectly asserts that the local UTC offset will never change, producing wrong results for date arithmetic across DST transitions.
Section 4.3 of RFC 3339 is updated so that offset Z means 'UTC time is known but local offset is unknown', differing semantically from +00:00, which retains the implication that UTC is the preferred reference point. The offset -00:00 is noted as less interoperable but not formally deprecated; Z should be used in its place.
Suffix keys starting with an underscore are reserved for controlled experiments and MUST NOT be used for interchange. Implementations not specifically configured to participate in such an experiment MUST reject these keys.
Suffix tags without the critical flag are elective: recipients are free to ignore any tag they do not recognize or cannot act upon. Applications MAY perform additional processing on inconsistent or unrecognized elective tags but are not required to.
When an application encounters duplicate use of a suffix key in elective suffixes and does not perform additional processing, it MUST choose the first suffix with that key and treat subsequent duplicates as absent.
When the time-offset in the RFC 3339 part is inconsistent with the time zone suffix and the critical flag is set on the time zone suffix, an application MUST act on the inconsistency (reject or resolve). Without the critical flag, the application MAY act on the inconsistency.
Attaching calendar system (u-ca) or other locale-related tags to a timestamp can reveal personal or demographic information about the originator. Generators should apply data minimization and omit such suffix tags when recipients are not trusted or when the disclosure is not necessary for the application.
A time zone suffix tag holds an IANA Time Zone name (e.g., Europe/Paris) or an offset time zone in numeric format (e.g., +08:45). Using a named IANA Time Zone implies the intent to use rules current at interpretation time, so the represented local time changes as the IANA Time Zone Database is updated.
The Internet Extended Date/Time Format (IXDTF) extends RFC 3339 by appending an optional suffix to a date-time value. The suffix consists of an optional time zone bracket tag followed by zero or more key=value bracket tags, each optionally marked critical with '!'.
The suffix key 'u-ca' is allocated to indicate the preferred calendar for presenting the date/time. Its allowed values are Unicode Calendar Identifiers as defined in Unicode Technical Standard #35, enabling calendar-aware applications to display timestamps in non-Gregorian calendars (e.g., Hebrew, Chinese).
IANA has created the 'Timestamp Suffix Tag Keys' registry in a new 'Internet Date/Time Format' registry group. Initial contents include the 'u-ca' key (Permanent). Registration policy is 'Specification Required' for permanent entries and 'Expert Review' for provisional ones.
Extending the RFC 3339 timestamp syntax introduces new parsing attack surface. No IXDTF-specific parsing vulnerabilities beyond the ordinary are identified, but implementers should apply standard defensive parsing practices.
IXDTF timestamps may constitute excessive disclosure: including time zone names, calendar system, or language preferences reveals information about the originator that may violate the data minimization principle. Generators must assess whether such information is appropriate to divulge and err on the side of omission when the recipient set is not under the originator's control.
Where IXDTF timestamps are embedded in access control information or other security-sensitive contexts requiring consistent interpretation across multiple actors, only extensions with a well-understood shared resolution of inconsistent data may be employed. Unresolved inconsistencies between UTC offset and time zone in such contexts can lead to authorization bypasses or incorrect access decisions.
IXDTF is defined as date-time-ext = date-time suffix, where suffix = [time-zone] *suffix-tag. A time-zone is '[' [critical-flag] (time-zone-name / time-numoffset) ']'; a suffix-tag is '[' [critical-flag] suffix-key '=' suffix-values ']'; critical-flag is the optional '!' character immediately after the opening bracket.
Suffix keys (suffix-key) consist of a lowercase letter or underscore followed by lowercase letters, digits, or hyphens. Suffix values (suffix-values) are one or more alphanumeric items delimited by hyphens. Time zone names follow time-zone-part = time-zone-initial *time-zone-char, with '.' and '..' explicitly excluded.