Date and Time on the Internet: Timestamps
updated by
- rfc-9557 — Date and Time on the Internet: Timestamps with Additional Information
Extracted elements (306)
A balance is struck between human readability and interoperability: the format "10/11/1996" is globally ambiguous, and the RFC 822 textual month abbreviations led to implementations substituting translated or non-standard forms, causing interoperability failures.
All dates and times are assumed to be in the current era (0000AD–9999AD) and all expressed times have a stated UTC offset. This deliberately avoids the complexity of scheduling applications where the local-to-UTC mapping may depend on unknowable future political decisions.
All timestamps must express a stated relationship (offset) to UTC. The specification explicitly excludes unqualified local time because interpretation would fail for approximately 23/24 of the globe, making its interoperability problems unacceptable.
Alphabetic time zone abbreviations (e.g., "EST", "PST") were rejected because past attempts to label local offsets with alphabetic strings resulted in poor interoperability. RFC 2822 mandated numeric offsets for the same reason.
Alphabetic time zone strings (as in the original RFC 822 email format) caused poor interoperability because different implementations assigned different UTC offsets to the same abbreviation; RFC 2822 subsequently mandated numeric offsets, a decision this profile adopts.
Alphabetic timezone abbreviations were made non-permissible because attempts to label local offsets with alphabetic strings have resulted in poor interoperability historically (RFC 822 experience), leading RFC 2822 to mandate numeric offsets.
Alphabetic timezone labels (e.g., 'EST') are deprecated and numeric offsets made mandatory because alphabetic strings caused poor interoperability historically; RFC 2822 codified the numeric requirement for email.
Alphabetic timezone labels (e.g. military single-letter codes) have historically caused poor interoperability in email, which is why RFC 2822 mandated numeric offsets. This specification follows the same approach, expressing all offsets numerically as local-time-minus-UTC.
Alphabetic timezone strings were explicitly excluded because prior use in Internet mail caused interoperability failures; RFC 2822 subsequently made numeric offsets mandatory in email.
Ambiguous human-readable date formats such as '10/11/1996' are unsuitable for global interchange because they are interpreted differently in different countries; a balance between human readability and strict machine-parseable formatting was required.
An offset of "-00:00" indicates the UTC time is known but the local offset is unknown, distinguishing it semantically from "+00:00" or "Z" which imply UTC is the preferred reference point.
Components are ordered from least precise (year) to most precise (second/fraction), enabling timestamps in the same timezone with the same fractional-second precision to be correctly sorted lexicographically using strcmp(), without requiring date-parsing logic.
Components are ordered from most significant (year) to least significant (second) so that timestamps expressed in the same timezone with the same fractional-second precision can be sorted correctly as plain strings using strcmp().
Date and time components are ordered from least precise to most precise (year, month, day, hour, minute, second) so that, when times share the same UTC offset and fractional-second precision, timestamps sort correctly as plain strings.
Date and time components are ordered from most significant (year) to least significant (second), so that timestamps with the same time zone and fractional-second precision can be sorted lexicographically using a simple string comparison (e.g., C's strcmp()).
Date/time components are ordered from least precise (year) to most precise (second/fraction) so that, given identical time zones and fractional-second digit counts, timestamps sort correctly using a simple lexicographic (strcmp) comparison.
Day of the week is intentionally excluded from the format because it is redundant (computable from the date) and its inclusion would introduce the possibility of inconsistency between the stated day and the actual calendar date.
Day-of-week is deliberately excluded from the format because it is redundant (computable from the date) and its inclusion would introduce the possibility of inconsistency between the day-of-week field and the calendar date.
Day of week is excluded from the format because it is redundant (computable from the date) and redundant information introduces the possibility of inconsistency between the stated day and the date.
Day of week is intentionally excluded from the format because it is redundant (computable from the date) and its inclusion would create the possibility of inconsistencies between the day-of-week field and the date.
Fields are ordered from least precise (year) to most precise (second/fraction), enabling lexicographic string comparison (e.g., strcmp()) to yield chronological ordering, provided all timestamps share the same UTC offset string.
Four-digit years are required because the problems with two-digit years (Y2K-class ambiguities, three-digit representations, non-numeric decade characters) amply demonstrate why all dates and times in Internet protocols must be fully qualified.
Fractional seconds are the only optional element retained in the profile. They are expected to be used only by applications requiring strict ordering or unusual precision; their rarity means they are unlikely to cause interoperability problems compared to other rarely used ISO 8601 options.
Fractional seconds are the only rarely-used option retained in the format. Rarely-used options cause interoperability problems because they receive less testing; retaining only fractional seconds limits this risk while satisfying strict ordering and high-precision use cases.
Fractional seconds are the only rarely-used optional component retained. Rarely-used options cause interoperability failures because they receive less testing; all other options were made mandatory or omitted.
Fractional seconds is the only optional element in the format, retained because it is needed by applications requiring strict timestamp ordering or unusual precision. All other rarely-used ISO 8601 options were made mandatory or omitted to avoid parser bugs.
Fractional seconds (time-secfrac) are the only rarely-used optional element retained in the format; they are expected only for applications requiring strict timestamp ordering or unusual precision. All other optional ISO 8601 elements are omitted to reduce parsing bugs.
Fractional seconds (time-secfrac) is the only optional element retained in the profile because it is rarely needed and expected only for applications requiring strict ordering or unusual precision; rarely used options are more likely to have parsing bugs discovered late.
Fractions of a second are the sole rarely-used option retained in the format, expected only for applications requiring strict ordering or unusual precision. Rarely used options are avoided because they are less likely to be tested and bugs in parsing are more likely to remain undiscovered.
If date and time components are ordered from least precise (year) to most precise (second/fraction), timestamps can be sorted lexicographically using strcmp() when zones and fractional-digit counts are uniform. Optional punctuation would violate this property.
Non-integral minute UTC offsets (which exist in historical time zones, e.g., Netherlands +00:19:32.13 before 1937) cannot be represented exactly in the HH:MM offset format; applications must convert such timestamps to the closest representable UTC offset.
Numeric offsets are mandatory instead of alphabetic timezone strings because alphabetic strings resulted in poor interoperability historically (per RFC 822 experience). RFC 2822 also mandated numeric offsets for this reason.
Numeric offsets are mandatory (over alphabetic timezone strings) because previous attempts to label offsets with alphabetic strings resulted in poor interoperability, as documented in RFC 822 and RFC 1123 experience.
Numeric offsets are mandatory (rather than alphabetic timezone strings) because alphabetic timezone strings have historically caused poor interoperability, as documented in RFC 822 and RFC 1123. RFC 2822 made numeric offsets mandatory in email for the same reason.
Numeric offsets follow only ISO 8601 zones that differ from UTC by an integral number of minutes. Historical time zones with non-integral-minute offsets (e.g., Netherlands +00:19:32.13) must be approximated to the nearest representable offset.
Numeric UTC offsets are mandated (and alphabetic timezone abbreviations prohibited) because past attempts to label offsets with alphabetic strings caused poor interoperability in Internet mail, as documented in RFC 822 and RFC 1123 experience.
Numeric UTC offsets are mandatory rather than alphabetic timezone abbreviations because alphabetic strings (e.g., 'EST', 'PST') caused poor interoperability in email systems historically.
Numeric UTC offsets are mandatory (replacing alphabetic timezone labels) because alphabetic strings caused poor interoperability in early Internet mail, as documented in RFC 822 and RFC 1123. Numeric offsets are calculated as local time minus UTC.
Numeric UTC offsets are used instead of alphabetic time zone strings because attempts to label local offsets with alphabetic strings resulted in poor interoperability historically. As a result, RFC 2822 made numeric offsets mandatory, and this profile follows that precedent.
Rarely used optional features are omitted or made mandatory because they receive less testing and thus harbor more parser bugs. The only rarely used option retained is fractional seconds, expected only for applications requiring strict ordering or unusual precision.
Rarely used options are avoided because they receive less testing in alpha/beta stages, causing bugs to go undiscovered. Fractional seconds is the only optional feature retained, expected only for applications requiring strict ordering or unusual precision.
Rarely used options are excluded wherever possible because they are less likely to be tested, causing parser bugs to go undetected. Fractional seconds are the only optional element retained, for applications with strict ordering or precision requirements.
Rarely-used options are kept to a minimum (only fractional seconds) because such options receive less testing and therefore cause more interoperability problems. Optional features should be made mandatory or omitted whenever possible.
Rarely used options are likely to contain parser bugs discovered only in production. The profile therefore omits most ISO 8601 optional features, retaining only fractional seconds as optional, expected to be used only by applications requiring strict ordering or unusual precision.
Rarely used options are likely to harbour undetected parsing bugs because they receive less testing. Fractional seconds is the only retained optional element, and only because some applications require sub-second precision or strict ordering.
Rarely used options are omitted or made mandatory to avoid interoperability failures: bugs in parsers for rarely used options are unlikely to be caught in testing. Fractional seconds is the only retained optional field, expected only for applications requiring strict ordering or unusual precision.
Rarely used options (beyond fractional seconds) are excluded because they are less likely to be tested during alpha/beta testing, leading to undetected parsing bugs and interoperability problems. Fractions of a second are the sole retained option.
Redundant information such as day-of-week is excluded from the format because it introduces the possibility of inconsistency (the day-of-week could disagree with the date) and can be computed from the date unambiguously.
RFC 3339 defines a strict profile of ISO 8601 rather than adopting the full grammar because ISO 8601's complete syntax is too complex for Internet protocols: it includes partial representations, redundant forms, and rarely exercised options that reduce interoperability by escaping test coverage.
The '-00:00' unknown offset convention was adopted (mirroring RFC 2822) to distinguish 'UTC is known, local offset is unknown' from '+00:00' or 'Z', which both imply UTC is the authoritative reference for the given time.
The complete ISO 8601 grammar is deemed too complex for Internet protocols due to its many optional representations and partial representations; this document defines a strict conformant subset (extended format) that makes most fields and punctuation mandatory.
The complete ISO 8601 grammar was deemed too complex for Internet protocols; this RFC defines a simpler conformant subset that makes most fields and punctuation mandatory, eliminating rarely used options except fractional seconds.
The complete ISO 8601 grammar was rejected in favor of a constrained profile because the full ISO 8601 syntax is too complex, includes multiple and partial representations, and Internet protocols need complete data specification for true interoperability.
The day of the week is deliberately excluded from the format to eliminate redundant information that could be inconsistent with the calendar date; it is computable from the date alone.
The day of the week is excluded from the format because it is redundant information computable from the date, and redundant information introduces the possibility that the two representations will not correlate.
The day of the week is intentionally excluded from the format because it is redundant information that could be inconsistent with the date, and can be computed algorithmically (see Appendix B). Including redundant fields creates the possibility of conflicting values.
The day of week is deliberately excluded from the format: it is redundant (computable from the date) and its inclusion would introduce the possibility of inconsistency between the day-of-week field and the date fields.
The day of week is excluded from the format because it is redundant — it can be computed from the date — and redundant information introduces the possibility of inconsistency between the day-of-week field and the actual date.
The day of week is intentionally excluded from the format to avoid redundant information: an inconsistent day-of-week field would introduce ambiguity, and the day of week can always be computed from the date alone.
The format "10/11/1996" is explicitly cited as completely unsuitable for global interchange because it is interpreted differently in different countries, motivating the choice of an unambiguous ISO 8601-derived format with fixed field order and width.
The format is a deliberately simplified conformant subset of ISO 8601 extended format, making most fields and punctuation mandatory. The full ISO 8601 grammar was deemed too complex for Internet protocol use; only fractional seconds remain optional.
The format orders components from least precise (year) to most precise (second/fraction), enabling lexicographic string comparison (e.g., strcmp) to produce chronological ordering—provided all timestamps share the same time zone string and fractional-second digit count. Optional punctuation or variable-length components would break this property.
The format restricts the hour to values 00-23, explicitly excluding the ISO 8601 value of 24, in order to reduce confusion. ISO 8601 permits hour 24 to denote midnight at end of day.
The format was designed as a strict profile of ISO 8601 rather than the full grammar, because the complete ISO 8601 syntax is too complex for Internet protocols. Simplicity is achieved by making most fields and punctuation mandatory, eliminating optional elements that cause interoperability bugs.
The fractional seconds component (`time-secfrac`) is the only optional element retained in the format. The complete ISO 8601 grammar is deemed too complex; simplicity is achieved by making all other fields and punctuation mandatory.
The full ISO 8601 grammar (Appendix A) is deemed too complex for Internet protocols; simplicity is achieved by making most fields and punctuation mandatory in this profile, eliminating optional representations and partial representations present in ISO 8601.
The full ISO 8601 grammar (documented in Appendix A) is deemed too complex for Internet protocols. This specification defines a simpler conformant subset of ISO 8601 extended format by making most fields and punctuation mandatory.
The full ISO 8601 grammar is deemed too complex for most Internet protocols. This profile achieves simplicity by making most fields and punctuation mandatory and including only one optional element: fractional seconds.
The full ISO 8601 grammar is too complex for Internet use; this profile achieves simplicity by making most fields and punctuation mandatory, leaving fractions of a second as the only optional element.
The full ISO 8601 grammar was deemed too complex for Internet protocols; this document defines a strict conformant subset that makes most fields and punctuation mandatory, eliminating rarely used options (except fractional seconds) to reduce parsing bugs from untested code paths.
The hour field is restricted to 00-23 even though ISO 8601 permits the value 24, in order to reduce confusion. This is an intentional deviation from ISO 8601.
The hour value is restricted to 00-23 (excluding the ISO 8601-permitted value of 24) to reduce confusion, even though ISO 8601 permits hour=24 to represent midnight at the end of a day.
The human-readable format "10/11/1996" is unsuitable for global interchange because different countries interpret it differently; a balance between human readability and unambiguous machine parsing motivates the chosen ISO 8601 profile with fixed-length numeric fields and mandatory separators.
The only rarely-used option included in the format is fractional seconds (time-secfrac), because rarely-used options are less likely to be tested in alpha/beta and thus more likely to harbor parsing bugs. Fractional seconds are retained for applications requiring strict timestamp ordering or unusual precision.
The optional fractional seconds field is the only rarely used option retained in the format; all other rarely used ISO 8601 options were omitted to improve interoperability, since rarely used options are less likely to be tested.
The scope of the format is intentionally limited to timestamps (instants in time) for current-era dates (0000AD–9999AD) with a stated UTC relationship; time periods, intervals, recurring events, and scheduling semantics are explicitly out of scope.
The specification covers only timestamps for Internet protocol events (instants in time) and excludes time periods, intervals, and scheduling with ambiguous future daylight-saving transitions. This limited scope simplifies the format and avoids political/administrative uncertainties.
The specification steers clear of local time zone and daylight-saving rule complexity because political and administrative decisions can change the UTC offset of a local time unpredictably, preventing true interoperability.
The 'T' separator between date and full-time is required (rather than optional as in some ISO 8601 contexts) to avoid parsing ambiguity, at the cost of reduced human readability.
True interoperability is best achieved using UTC because daylight saving rules for local time zones are convoluted and can change unpredictably based on local law; this specification does not cater to local time zone rules.
Two-digit years are deprecated because ambiguity causes protocol and processing failures. The Y2K problems demonstrate why all dates and times in Internet protocols must be fully qualified with four-digit years.
Two-digit years are deprecated because they are inherently ambiguous and have caused protocol failures; all dates in Internet protocols MUST be fully qualified with four-digit years to avoid Y2K-class problems.
Two-digit years are deprecated because they introduce ambiguity and because programs that compute years as offsets from 1900 can produce three-digit or non-numeric representations for years after 1999, demonstrating why all dates and times in Internet protocols MUST be fully qualified.
Two-digit years are deprecated because Y2K-era implementations produced ambiguous three-digit years (subtracting 1900) or non-numeric decade characters, demonstrating that all protocol dates and times must be fully qualified.
Unlike ISO 8601, which permits omitting the 'T' separator between date and time in some circumstances, this profile requires 'T' to avoid ambiguity, especially in contexts where the separator might otherwise be confused with other characters.
Unqualified local time is deemed unacceptable for Internet protocols because interpretation will fail in approximately 23 out of 24 time zones around the globe, making interoperability effectively impossible.
Unqualified local time is explicitly rejected for Internet use because interpretation of a time without a UTC offset will fail for approximately 23/24 of the globe, making the interoperability problems unacceptable.
UTC is chosen as the baseline rather than local time because daylight saving rules are convoluted and can change unpredictably; true interoperability is best achieved by expressing all times relative to UTC.
UTC is chosen as the reference for Internet timestamps because daylight saving rules for local time zones are convoluted and can change unpredictably based on local law, making true interoperability dependent on UTC.
UTC is mandated as the reference for all Internet timestamps because daylight saving rules for local time zones are convoluted, can change unpredictably based on local law, and prevent true interoperability. The specification explicitly does not cater to local time zone rules.
UTC is mandated rather than local time because daylight saving rules for local time zones are convoluted and can change at unpredictable times based on local law, making true interoperability impossible with local times alone.
UTC is preferred over local time because daylight saving rules are convoluted and can change unpredictably based on local law. The specification explicitly does not cater to local time zone rules in order to achieve true interoperability.
UTC is preferred over local time for Internet timestamps because daylight saving rules are convoluted and can change unpredictably based on local law, making true interoperability depend on a stable universal reference.
UTC is preferred over local time zones because daylight saving rules are convoluted and can change unpredictably based on local law, making true interoperability impossible without a stable reference point.
UTC is strongly preferred over local time because daylight saving rules are convoluted and can change unpredictably based on local law, making true interoperability impossible without a common reference. The spec explicitly avoids modeling local-timezone-aware scheduling semantics.
UTC is the required reference for Internet timestamps because daylight saving rules for local time zones are convoluted and can change at unpredictable times based on local law, making true interoperability impossible with local times.
Alphabetic time zone labels (as used in early email) have caused poor interoperability in the past; RFC 2822 made numeric offsets mandatory. This specification adopts numeric offsets exclusively.
Alphabetic timezone label strings have historically resulted in poor interoperability; numeric offsets expressed as local time minus UTC are mandatory. The offset +00:20 in the 1937 Netherlands example illustrates handling non-standard historical offsets.
Alphabetic timezone strings (as used in older email formats) have resulted in poor interoperability; RFC 2822 therefore made numeric offsets mandatory. RFC 3339 follows this precedent by requiring numeric time-numoffset.
An offset of "-00:00" indicates that UTC is known but the local offset is unknown. This is semantically distinct from "+00:00" or "Z", which imply UTC is the preferred reference point. This convention follows RFC 2822.
Applications may replace the "T" separator with a space character for human readability in environments that permit it. Implementations parsing this format should be prepared to accept either separator.
Applications may substitute a space character for 'T' between full-date and full-time for readability in contexts where the separator character is unambiguous. This is explicitly noted as a permissible deviation for readability.
Applications MAY use a space or other separator in place of the 'T' between full-date and full-time for readability in contexts where this is unambiguous, but the ABNF-defined format uses 'T'.
Attempts to label local offsets with alphabetic strings have resulted in poor interoperability. RFC 2822 made numeric offsets mandatory; this specification follows the same approach.
Attempts to label local time-zone offsets with alphabetic strings (as in early RFC 822) have caused poor interoperability; RFC 2822 therefore mandates numeric offsets, and this profile inherits that requirement.
Attempts to label local UTC offsets with alphabetic timezone strings (as in old RFC 822) resulted in poor interoperability. RFC 2822 made numeric offsets mandatory; this profile follows the same approach.
Broken software subtracting 1900 from a year may produce three-digit years for post-1999 dates, or non-numeric decade characters. Robust implementations may add 1900 to three-digit years or detect and appropriately handle non-numeric decade fields.
Broken two-digit-year software may produce three-digit years (e.g., year 2000 as "100") or non-numeric decade characters. Robust implementations may add 1900 to three-digit years and should detect and interpret non-numeric decades appropriately.
For lexicographic sorting of timestamps to produce time-ordered results, all timestamps must share the same timezone string (all 'Z' or all '+00:00') and the same number of fractional-second digits; optional punctuation or differing offset representations break this property.
For readability purposes, applications may use a space character instead of "T" to separate the full-date and full-time components when the format is used in contexts that do not require strict ISO 8601 compliance.
For string-based lexicographic ordering to produce a time-ordered sequence, all compared timestamps must share the same UTC offset representation and the same number of fractional second digits. Mixed formats defeat strcmp-based sorting.
Historical time zones may differ from UTC by a non-integral number of minutes (e.g., Netherlands was +00:19:32.13 before 1937). Such timestamps cannot be represented exactly and must be converted to the nearest representable UTC offset.
Historical time zones that differ from UTC by a non-integral number of minutes (e.g., the Netherlands in 1937, at +00:19:32.13) cannot be represented exactly in HH:MM format; applications must convert such timestamps to the closest representable UTC offset.
If a 2-digit year is received, it should be accepted ONLY if an incorrect interpretation will not cause a protocol or processing failure (e.g., if used only for logging or tracing). Programs should also handle broken software that represents post-1999 years as three digits or non-numeric decades.
If date and time components are ordered from least to most precise (year, month, day, hour, minute, second) and all timestamps share the same offset string and fractional-second digit count, they can be sorted lexicographically as strings using strcmp().
If timestamps share the same time zone string (all "Z" or all "+00:00") and the same number of fractional second digits, they may be sorted lexicographically (e.g., with strcmp()) to yield a time-ordered sequence. Optional punctuation or varying formats would break this property.
In time zones other than 'Z', the leap second point is shifted by the zone offset so the leap second occurs at the same instant globally. For example, 1990-12-31T23:59:60Z equals 1990-12-31T15:59:60-08:00.
Internet clients SHOULD be prepared to transform RFC 3339 timestamps into a display format suitable for the user's locality, including translating UTC to local time, because no single date/time format is readable according to the conventions of all countries.
ISO 8601 numeric offsets represent only time zones differing from UTC by an integral number of minutes. Historical time zones with non-integral offsets (e.g., Netherlands +00:19:32.13) must be converted to the closest representable UTC offset.
ISO 8601 permits an hour value of '24', but this profile restricts hours to 00–23 to reduce confusion. Implementations parsing ISO 8601 input may encounter this value, but conformant RFC 3339 generators must not emit it.
ISO 8601 permits the "T" separator and "Z" suffix to be lowercase. Specifications in case-sensitive environments MAY further restrict the format to require uppercase; applications generating the format SHOULD use uppercase to maximize compatibility.
Leap second timestamps are shifted by the UTC offset in non-Z time zones, occurring at the same instant globally. For example, a leap second at 23:59:60Z also appears as 15:59:60-08:00 in Pacific Standard Time.
Leap seconds cannot be predicted far in advance; the IERS announces them with only a few weeks' warning. Applications must not generate leap-second timestamps before the announcement.
Leap seconds cannot be predicted far into the future; the IERS publishes bulletins announcing them with only a few weeks' warning. Applications processing timestamps near a known leap second point must handle time-second=60 without treating it as an error.
Leap seconds occur simultaneously across all time zones; in non-UTC zones the leap second point is shifted by the zone offset so it happens at the same instant globally. For example, 1990-12-31T23:59:60Z equals 1990-12-31T15:59:60-08:00.
Leap seconds occur simultaneously in all time zones, so the leap second point shifts by the zone offset in non-UTC representations (e.g., 1990-12-31T15:59:60-08:00 equals 1990-12-31T23:59:60Z). Implementations must account for this shift when comparing timestamps across zones.
Lexicographic (string) sorting of timestamps yields a time-ordered sequence only when all timestamps use the same time zone string, the same offset form, and the same number of fractional-second digits; optional punctuation or mixed offset representations break this property.
Many historical time zones differ from UTC by a non-integral number of minutes; since numeric offsets only represent integral-minute differences, applications must convert such historical timestamps to the closest representable UTC offset.
Numeric offsets are mandatory; attempts to label local offsets with alphabetic timezone strings have resulted in poor interoperability in the past. Numeric offsets represent local time minus UTC, so UTC equivalent time is obtained by subtracting the offset.
Numeric offsets can only represent time zones differing from UTC by an integral number of minutes. Historical time zones with non-integral minute offsets (e.g. Netherlands +00:19:32.13) must be approximated to the nearest representable offset.
Numeric offsets can only represent time zones that differ from UTC by an integral number of minutes. Many historical time zones differ by non-integral minutes; applications must convert such timestamps to the nearest representable UTC offset.
Numeric offsets only represent time zones differing from UTC by an integral number of minutes; many historical time zones differ by a non-integral number of minutes. Applications must convert such timestamps to the closest representable UTC offset (e.g., the 1937 Netherlands example of +00:20).
Numeric offsets represent only time zones differing from UTC by an integral number of minutes. Many historical time zones differ by non-integral minutes; applications must convert such timestamps to the nearest representable UTC offset (e.g., the 1937 Netherlands offset of +00:19:32.13 becomes +00:20).
Numeric offsets represent only time zones that differ from UTC by an integral number of minutes. Historical time zones with non-integral offsets (e.g., the Netherlands +00:19:32.13 prior to 1937) must be converted to the closest representable UTC offset.
Numeric UTC offsets can only represent time zones that differ from UTC by an integral number of minutes. Historical time zones with non-integral-minute offsets (e.g., Netherlands +00:19:32.13) must be approximated to the nearest representable offset.
Per ISO 8601, numeric offsets represent only time zones that differ from UTC by an integral number of minutes. Historical time zones with non-integral-minute offsets (e.g., Netherlands +00:19:32.13) must be converted to the nearest representable offset.
Programs using 2-digit years may produce 3-digit years for years after 1999 (e.g., subtracting 1900 without digit-count checks) or non-numeric decade characters. Robust implementations should handle these broken representations by adding 1900 to 3-digit years.
Programs using 2-digit years may represent years after 1999 as three digits (by subtracting 1900 without checking digit count) or as non-numeric characters. Robust parsers may add 1900 to three-digit years or detect and handle non-numeric decade values.
Programs using two-digit years may represent years after 1999 as three digits (subtracting 1900 without checking digit count) or as non-numeric characters. Implementations wishing to handle such broken software may add 1900 to three-digit years or detect non-numeric decades.
Some environments may separate full-date and full-time with a space character instead of "T" for readability. Applications should be aware that the strict format requires "T" but relaxed parsing may be appropriate for human-entered data.
The date format '10/11/1996' is completely unsuitable for global interchange because it is interpreted differently across countries; similarly, translating three-letter month abbreviations to other languages breaks parsing.
The date format "10/11/1996" is unsuitable for global interchange because it is interpreted differently in different countries, illustrating why a fixed, unambiguous numeric format is required for Internet use.
The date-mday maximum value is month- and year-dependent (28–31 for day, with February varying by leap year). Implementations MUST validate date-mday against the actual month/year to avoid accepting invalid dates such as February 30.
The format may be used in case-sensitive environments (e.g., XML) where 'T' and 'Z' must be uppercase; applications generating the format should always use uppercase to maximize compatibility across such environments.
The hour value '24' permitted by ISO 8601 is not allowed in this profile; valid hour values are '00' through '23' only, to reduce confusion in implementations.
The "T" and "Z" characters in the date-time syntax may alternatively be lowercase "t" or "z" per [ABNF] and ISO 8601. Implementors in case-sensitive environments (e.g., XML) should be aware of this optionality.
The 'T' and 'Z' characters in the syntax may alternatively be lower-case 't' or 'z'. However, specifications used in environments that distinguish case (e.g., XML) MAY further restrict them to upper-case only.
The 'T' and 'Z' characters MAY be lower case 't' or 'z' per ABNF and ISO 8601, but applications generating the format SHOULD use upper case. Implementations must accept both cases unless the environment is case-sensitive.
The 'T' separator and 'Z' suffix are case-insensitive per ABNF and ISO 8601 (lower case 't' and 'z' are permitted), but some environments (e.g., XML) distinguish case — specifications in such environments MAY restrict to upper case only.
The 'T' separator and 'Z' suffix may alternatively be lower case 't' or 'z' per ABNF and ISO 8601. However, specifications operating in case-sensitive environments (e.g., XML) MAY restrict the format to require uppercase, so generators SHOULD use uppercase to maximize compatibility.
The 'T' separator and 'Z' suffix may be lowercase ('t' or 'z') per ABNF and ISO 8601, but applications generating the format SHOULD use uppercase. Case-sensitive environments (e.g. XML) MAY restrict to uppercase-only.
The 'T' separator between date and full-time may be replaced by a space for readability in applications that choose to do so, and 'T' and 'Z' may be lower case; environments that are case-sensitive (e.g., XML) may restrict to upper case only.
The "T" separator between date and time, and the "Z" suffix for UTC, may each be either upper or lower case per ABNF and ISO 8601. Applications in case-sensitive environments such as XML may restrict these to upper case only.
The "T" separator between date and time MAY be replaced by a space for readability in contexts where the sender and receiver agree, but the ABNF-defined format with "T" is the normative form for Internet protocols.
This profile restricts the hour field to values 00-23, disallowing the ISO 8601 value of '24', in order to reduce confusion among implementations.
This profile restricts time-hour to 00-23, disallowing the ISO 8601-permitted value of '24', in order to reduce confusion in parsing and interoperability.
Two-digit year programs may generate three-digit years (e.g., year 2000 as "100") or non-numeric decade characters. Robust receivers may compensate by adding 1900 to three-digit years or detecting non-numeric decades.
Two-digit year representations are deprecated. If a 2-digit year is received, it should be accepted ONLY if an incorrect interpretation will not cause a protocol or processing failure (e.g., logging only). Programs should also handle broken software producing 3-digit years or non-numeric decade characters.
Two-digit year representations can produce three-digit results (year - 1900 for years after 1999) or non-numeric decade characters. Implementations wishing to handle such broken software may add 1900 to three-digit years or detect and interpret non-numeric decades appropriately.
Two-digit year representations from broken software may appear as three digits (e.g., 100 for year 2000) if the program subtracts 1900 without checking digit count, or as non-numeric characters (e.g., ":0") if it adds the decade to ASCII zero. Robust implementations must handle both cases.
Two-digit-year software may emit three-digit years (year - 1900) for years after 1999, or non-numeric decade characters. Robust parsers may add 1900 to three-digit years and should detect and interpret non-numeric decade fields appropriately.
Two-digit-year software may emit years after 1999 as three digits (by subtracting 1900 without checking digit count) or as non-numeric characters. Robust parsers may compensate by adding 1900 to three-digit years or detecting non-numeric decades.
Two-digit years are deprecated. A received two-digit year should be accepted ONLY if an incorrect interpretation will not cause a protocol or processing failure. Programs using two-digit years may produce three-digit or non-numeric decade representations for years after 1999.
Unqualified local time is deemed unacceptable for Internet use because interpretation will fail in approximately 23 out of 24 regions; all Internet timestamps must carry an explicit UTC offset.
Unqualified local time is deemed unacceptable for the Internet because interpretation will fail in approximately 23/24 of the globe; all Internet timestamps must carry an explicit UTC offset.
Unqualified local time (with no UTC offset) is deemed unacceptable for the Internet because interpretation would fail in approximately 23 out of 24 possible time zones, making interoperability impossible.
Unqualified local time (without a UTC offset) is deemed unacceptable for Internet use because interpretation will fail for approximately 23 out of 24 locations on the globe.
A gateway host correcting unqualified local times MUST correct those times before transmitting to other hosts. Unqualified local time is deemed unacceptable for the Internet because interpretation fails in approximately 23/24 of the globe.
A gateway host in the same local time zone that is used to relay time to the Internet MUST correct unqualified local times before transmitting them to other hosts.
A gateway host that corrects local times for transmission to other Internet hosts MUST correct unqualified local times. Unqualified local time is deemed unacceptable for Internet use because it fails interoperability in approximately 23/24 of the globe.
A gateway host that relays unqualified local times to other hosts MUST correct those times to include a UTC offset before transmission.
A host acting as a gateway to the Internet on behalf of systems using unqualified local time MUST correct those unqualified local times before transmitting them to other hosts.
All dates and times used in Internet protocols MUST be fully qualified, i.e., they must include a stated relationship (offset) to UTC.
Although ISO 8601 permits the hour value "24", this profile only allows values between "00" and "23" for the hour field.
Applications should not generate timestamps involving inserted leap seconds until after those leap seconds are announced by the International Earth Rotation Service, since leap seconds cannot be predicted far into the future.
Applications that generate the date/time format SHOULD use upper case letters for "T" and "Z". Specifications operating in case-sensitive environments MAY further restrict the syntax to require upper case.
Applications that generate the Internet Date/Time Format SHOULD use upper case letters for 'T' and 'Z'. Specifications operating in case-sensitive environments (e.g., XML) MAY further restrict the syntax to require upper case.
Applications that generate this date/time format SHOULD use upper case letters for 'T' and 'Z'. Specifications operating in case-sensitive environments MAY further restrict the syntax to require upper case only.
Applications that generate this format SHOULD use upper case letters for the "T" and "Z" characters, though the ABNF permits lowercase "t" and "z" as alternatives.
Internet clients SHOULD be prepared to transform dates into a display format suitable for the locality, including translating UTC to local time, since no single date/time format is readable according to the conventions of all countries.
Internet Protocols MUST generate four-digit years in dates. Use of two-digit years is deprecated and may only be accepted if an incorrect interpretation will not cause a protocol or processing failure.
Specifications using this format in case-sensitive environments MAY further restrict the syntax to require uppercase 'T' and 'Z'.
Specifications using this format in environments that distinguish case MAY further limit the syntax to require uppercase "T" and "Z"; applications generating this format SHOULD use uppercase.
Systems configured with a local time but unaware of the corresponding UTC offset that depend on time synchronization with other Internet systems MUST use a mechanism that ensures correct synchronization with UTC (e.g., NTP, a gateway host that corrects local times, or prompting the user for time zone settings).
Systems configured with a local time that are unaware of the corresponding UTC offset and depend on time synchronization with other Internet systems MUST use a mechanism that ensures correct synchronization with UTC, such as NTP.
Systems configured with a local time, unaware of the corresponding UTC offset, and dependent on time synchronization with other Internet systems, MUST use a mechanism that ensures correct synchronization with UTC (e.g., NTP).
Systems configured with local time that are unaware of their UTC offset and depend on time synchronization with other Internet systems MUST use a mechanism that ensures correct synchronization with UTC, such as NTP or a gateway host that corrects unqualified local times.
Systems that are configured with a local time, are unaware of the corresponding UTC offset, and depend on time synchronization with other Internet systems MUST use a mechanism that ensures correct synchronization with UTC.
Systems that are configured with local time, are unaware of the corresponding UTC offset, and depend on time synchronization with other Internet systems MUST use a mechanism that ensures correct synchronization with UTC (e.g., NTP or a gateway host that corrects local times).
Systems that use local time, are unaware of the corresponding UTC offset, and depend on time synchronization with other Internet systems MUST use a mechanism that ensures correct synchronization with UTC (e.g., NTP).
The hour component MUST be in the range 00–23; although ISO 8601 permits hour "24", this profile explicitly disallows it to reduce confusion.
The hour field is restricted to values 00-23; the ISO 8601 option of hour=24 is not permitted in this profile in order to reduce confusion.
The Internet Date/Time Format defined in section 5.6 SHOULD be used in new Internet protocols. This profile of ISO 8601 mandates most fields and punctuation to achieve simplicity and interoperability.
The Internet Date/Time Format profile defined in section 5.6 SHOULD be used in new Internet protocols.
The Internet Date/Time Format profile of ISO 8601 defined in Section 5 SHOULD be used in new Internet protocols.
The Internet Date/Time Format SHOULD be used in new protocols on the Internet. This profile of ISO 8601 is a conformant subset of the ISO 8601 extended format with most fields and punctuation mandatory.
The time-second field MAY carry the value "60" only at the end of months in which a leap second occurs (June 30 or December 31). Applications should not generate timestamps involving inserted leap seconds until after the IERS announces them.
The time-second field MAY have the value "60" only at the end of months in which a leap second occurs. Applications SHOULD NOT generate timestamps involving inserted leap seconds until after the leap seconds are announced by IERS.
This profile of ISO 8601 allows only values between "00" and "23" for the hour field; the ISO 8601 value of "24" is not permitted, in order to reduce confusion.
This profile of ISO 8601 only allows hour values between '00' and '23'; the ISO 8601-permitted value of '24' is excluded to reduce confusion.
A leap second is represented as an extra second at the end of a day in UTC with a timestamp of the form YYYY-MM-DDT23:59:60Z. In non-UTC zones, the leap second point is shifted by the zone offset so it occurs at the same instant globally.
A timestamp is defined as an unambiguous representation of an instant in time, always carrying an explicit UTC offset. All timestamps in this profile are in the current era (0000AD–9999AD) and express a single instant, not a period or interval.
A timestamp represents an unambiguous instant in time, expressed as a full-date and full-time joined by 'T', always accompanied by a UTC offset. Timestamps cover dates from 0000AD to 9999AD and express instants only, not periods or intervals.
An Internet timestamp is an unambiguous representation of an instant in time expressed as a full-date 'T' full-time string with an explicit UTC offset. All timestamps must be in the range 0000AD to 9999AD and have a stated relationship to UTC.
An offset of "-00:00" indicates that the time in UTC is known but the local offset is unknown. This is semantically distinct from "+00:00" or "Z", which imply UTC is the preferred reference point for the specified time.
An offset of "-00:00" is a distinguished value meaning "UTC time is known but the local offset is unknown". This differs semantically from "+00:00" or "Z", which imply UTC is the preferred reference point.
An offset of "-00:00" is a reserved convention meaning the time in UTC is known but the local offset is unknown. This differs semantically from "+00:00" or "Z", which imply UTC is the preferred reference point.
An offset of "-00:00" is the defined convention for a timestamp where the UTC instant is known but the local offset is unknown. This differs semantically from "+00:00" or "Z", which imply UTC is the preferred reference point.
An offset of '-00:00' represents a timestamp where UTC time is known but the local offset is unknown. This is semantically distinct from '+00:00' or 'Z', which imply UTC is the preferred reference point.
An offset of "-00:00" signals that the time in UTC is known but the local offset is unknown. This is semantically distinct from "+00:00" or "Z", which imply UTC is the preferred reference point.
An unknown local UTC offset is represented by the special value "-00:00", which is semantically distinct from "+00:00" or "Z": the latter two imply UTC is the preferred reference point, while "-00:00" means UTC is known but the local offset is not.
date-mday maximum value varies by month and year: January/March/May/July/August/October/December allow 31, April/June/September/November allow 30, February allows 28 in normal years and 29 in leap years.
Fractional seconds (time-secfrac) are the only optional element in the Internet Date/Time Format. They are expected only for applications requiring strict ordering or unusual precision.
Leap seconds are represented as a time-second value of "60" in timestamps of the form YYYY-MM-DDT23:59:60Z, occurring simultaneously in all time zones; in non-UTC zones the leap second is represented at the shifted local equivalent time.
Leap seconds are represented by a time-second value of '60', occurring as an extra second at the end of a UTC day: YYYY-MM-DDT23:59:60Z. In non-UTC time zones, the leap second point shifts by the zone offset so it occurs at the same instant globally.
Leap seconds are represented by setting time-second to '60'. A leap second inserted at end of day appears as YYYY-MM-DDT23:59:60Z and occurs simultaneously in all time zones; the point is shifted by offset in non-UTC zones.
Leap seconds are represented by the value "60" in the time-second field, occurring at the end of certain months (historically June 30 or December 31), expressed as YYYY-MM-DDT23:59:60Z. A negative leap second would reduce the maximum time-second value to "58".
Leap seconds are represented by time-second = '60', occurring at the end of months in which a leap second is inserted (historically June 30 or December 31), expressed as YYYY-MM-DDT23:59:60Z. A subtracted leap second allows time-second = '58'.
Leap seconds occur simultaneously in all time zones; in time zones other than "Z", the leap second point is shifted by the zone offset so that the same instant is represented globally.
Numeric offsets are calculated as "local time minus UTC". The equivalent UTC time is determined by subtracting the offset from the local time (e.g., 18:50:00-04:00 equals 22:50:00Z).
Numeric offsets represent only time zones that differ from UTC by an integral number of minutes, per ISO 8601. Historical time zones with non-integral minute offsets (e.g., Netherlands +00:19:32.13) must be approximated to the nearest representable offset.
Numeric time offsets are calculated as 'local time minus UTC', so the equivalent UTC time is obtained by subtracting the offset from local time. For example, 18:50:00-04:00 is the same instant as 22:50:00Z.
Numeric UTC offsets are calculated as 'local time minus UTC'. Offsets represent only time zones differing from UTC by an integral number of minutes, per ISO 8601.
Numeric UTC offsets are expressed as `("+" / "-") HH:MM` and are calculated as "local time minus UTC". Alphabetic time zone labels are explicitly not used due to their history of causing interoperability failures.
The date-mday field's maximum value depends on the month and year: 28 for February in a normal year, 29 in a leap year, 30 for April/June/September/November, and 31 for all other months. Hour values are restricted to 00-23 (ISO 8601's hour value of 24 is not permitted).
The date-mday field's maximum value varies by month and year: 31 for January/March/May/July/August/October/December, 30 for April/June/September/November, 28 for February in normal years, and 29 in leap years.
The date-mday maximum value is month- and year-dependent: 28 for February in normal years, 29 in leap years, 30 for April/June/September/November, and 31 for January/March/May/July/August/October/December. The hour field is restricted to 00-23 even though ISO 8601 permits 24.
The date-mday maximum varies by month and year: 28 for February in normal years, 29 in leap years, 30 for April/June/September/November, and 31 for all other months.
The date-time construct represents a single instant in time as a full-date, the literal 'T' separator, and a full-time. The format is a conformant subset of ISO 8601 extended format covering years 0000AD through 9999AD with a mandatory UTC offset.
The date-time element encodes a fully qualified instant in time as full-date "T" full-time, with full-date carrying a 4-digit year, 2-digit month, and 2-digit day, and full-time carrying hours, minutes, seconds, optional fractional seconds, and a mandatory UTC offset.
The date-time format defines a timestamp as an ISO 8601 profile with mandatory fields: four-digit year, two-digit month, two-digit day, two-digit hour, two-digit minute, two-digit second, optional fractional seconds, and a mandatory UTC offset or 'Z'.
The date-time value represents an unambiguous instant in time, combining a full-date (YYYY-MM-DD) and full-time (HH:MM:SS[.frac][offset]), always with a stated UTC offset. Years range from 0000 to 9999 AD.
The grammar element time-second may have the value '60' at the end of months containing a positive leap second (XXXX-06-30T23:59:60Z or XXXX-12-31T23:59:60Z). For a negative leap second, the maximum value of time-second is '58'.
The hour component is restricted to values 00-23; although ISO 8601 permits 24, this profile disallows it to reduce confusion.
The hour field is restricted to values 00–23; the ISO 8601 value of "24" is not permitted in this profile in order to reduce confusion.
The Internet Date/Time Format is a conformant subset of the ISO 8601 extended format. It represents a single instant in time in the range 0000AD–9999AD with a mandatory UTC offset, and excludes time periods, intervals, and unqualified local times.
The Internet Date/Time Format is defined as: date-time = full-date "T" full-time, where full-date = date-fullyear "-" date-month "-" date-mday and full-time = partial-time time-offset. This is a conformant subset of ISO 8601 extended format with most fields and punctuation mandatory.
The offset "-00:00" is a reserved convention meaning UTC is known but the local offset is unknown. This is semantically distinct from "+00:00" or "Z", which imply UTC is the preferred reference point for the specified time.
The time-offset element is either the literal "Z" (UTC, offset +00:00) or a numeric offset of the form "+HH:MM" or "-HH:MM" representing local time minus UTC. Alphabetic timezone strings are not permitted.
The time-offset element is either "Z" (UTC, offset 00:00) or a numeric offset expressed as ('+' / '-') HH:MM, calculated as local time minus UTC. Alphabetic time zone labels are explicitly rejected due to past interoperability failures.
The time-offset field encodes the relationship of local time to UTC: "Z" means UTC exactly (+00:00), a numeric time-numoffset of the form (+/-)HH:MM means local time minus UTC, and "-00:00" is a special convention meaning UTC is known but the local offset is unknown.
The time-offset field is either 'Z' (UTC) or a numeric offset in the form (+/-)HH:MM representing local time minus UTC. Alphabetic timezone designators are not permitted; all offsets must be numeric.
The time-secfrac element ("." followed by one or more digits) is the only optional component in the format. It is expected to be used only by applications requiring strict ordering or unusual precision.
The time-secfrac field ('.' 1*DIGIT) is the only optional component in the format, providing sub-second precision. It is expected to be used only by applications requiring strict ordering or unusual precision.
The time-secfrac field represents fractional seconds as "." followed by one or more digits. It is the only optional component in the Internet Date/Time Format, intended for applications requiring strict ordering or unusual precision.
The time-second field allows the value '60' at the end of months in which a leap second occurs (historically end of June or December, e.g. XXXX-06-30T23:59:60Z). A subtracted leap second reduces the maximum to '58'.
The time-second field may have the value "60" at the end of months in which a positive leap second occurs (historically June 30 or December 31, expressed as XXXX-MM-DDT23:59:60Z). If a leap second is subtracted, the maximum value is "58".
The `time-second` field may take the value "60" to represent an inserted leap second, occurring at the end of months when a leap second is added (historically June 30 or December 31, expressed as XXXX-06-30T23:59:60Z or XXXX-12-31T23:59:60Z). A subtracted leap second reduces the maximum to "58".
The top-level grammar production is date-time = full-date "T" full-time, representing an unambiguous instant in time with a mandatory UTC offset. This is a conformant subset of ISO 8601 extended format.
The unknown local offset convention uses '-00:00' to indicate that the UTC time is known but the local offset is unknown. This differs semantically from '+00:00' or 'Z', which imply UTC is the preferred reference point.
The unknown local offset convention uses an offset of "-00:00" to indicate that the time in UTC is known but the offset to local time is unknown. This differs semantically from "+00:00" or "Z", which imply UTC is the preferred reference point.
The unknown local offset is represented as "-00:00", which is semantically distinct from "+00:00" or "Z": the latter two imply UTC is the preferred reference point, while "-00:00" signals that the UTC offset is unknown.
The UTC offset "-00:00" is a convention meaning the UTC time is known but the local offset is unknown. It differs semantically from "+00:00" or "Z", which imply UTC is the preferred reference point.
The local time zone embedded in a timestamp may reveal when systems are less likely to be monitored and more susceptible to security probes; sites concerned about this may choose to emit times in UTC only.
The local time zone offset embedded in a timestamp may reveal geographic location and help an attacker determine when systems are less likely to be monitored. Sites concerned about this may choose to emit timestamps in UTC only (using 'Z').
The local time zone offset in a timestamp may reveal the geographic location of a site, enabling attackers to infer times when systems are less monitored and more susceptible to probing. Sites concerned about this may wish to emit timestamps in UTC only (using 'Z' offset).
The local time zone offset included in a timestamp may reveal information about a site's geographic location and normal business hours, potentially enabling an attacker to identify times when systems are less likely to be monitored and more susceptible to probing. Sites may choose to emit times in UTC only to mitigate this risk.
Timestamps that include a local time zone offset may reveal the geographic location of a site and indicate times when systems are less likely to be monitored, potentially aiding adversaries in selecting opportune windows for security probes. Sites may choose to emit times in UTC only to mitigate this.
Date fields use fixed-width decimal: date-fullyear = 4DIGIT, date-month = 2DIGIT (01-12), date-mday = 2DIGIT (01-28/29/30/31 depending on month/year). All punctuation (hyphens, colons, "T") is mandatory.
`date-fullyear` is 4DIGIT; `date-month` is 2DIGIT (01-12); `date-mday` is 2DIGIT (01-31, month/year constrained); `time-hour` is 2DIGIT (00-23); `time-minute` is 2DIGIT (00-59); `time-second` is 2DIGIT (00-60 to accommodate leap seconds); `time-secfrac` is "." followed by one or more digits.
date-fullyear is exactly 4 ASCII digits (0000–9999); date-month is 2 digits (01–12); date-mday is 2 digits whose maximum value depends on month and year (28–31); time-hour is 2 digits (00–23); time-minute is 2 digits (00–59); time-second is 2 digits (00–58, 00–59, or 00–60 depending on leap-second rules).
date-mday is 2DIGIT with a maximum value that varies by month and year: 28 or 29 for February (depending on leap year), 30 for April/June/September/November, and 31 for remaining months. The hour field is restricted to 00–23; ISO 8601's value of 24 is not permitted.
Fractional seconds are encoded as time-secfrac = "." 1*DIGIT appended to time-second. This is the only optional element in the format; all other fields and punctuation are mandatory.
Fractional seconds are expressed as `time-secfrac = "." 1*DIGIT`, appended after `time-second` within `partial-time`. This is the only optional element in the format; all other fields and punctuation are mandatory.
Leap seconds are represented by setting time-second to "60" at the end of a month in which a leap second occurs (historically June 30 or December 31), expressed as XXXX-MM-DDT23:59:60Z. A subtracted leap second makes the maximum time-second value "58".
The date-fullyear field is exactly 4DIGIT; date-month is 2DIGIT (01-12); date-mday is 2DIGIT (01-31 depending on month/year); time-hour is 2DIGIT (00-23); time-minute is 2DIGIT (00-59); time-second is 2DIGIT (00-60 accounting for leap seconds); time-secfrac is "." followed by 1 or more digits.
The `date-fullyear` field is exactly 4DIGIT (e.g., 1985), `date-month` is 2DIGIT (01–12), and `date-mday` is 2DIGIT with a maximum that varies by month and leap year status.
The date-mday field maximum value is month- and year-dependent: February has 28 in normal years and 29 in leap years; April, June, September, November have 30; all other months have 31. The hour field is restricted to 00-23; ISO 8601's value of 24 is not permitted.
The date-time format is: date-time = full-date "T" full-time, where full-date = date-fullyear "-" date-month "-" date-mday (4-2-2 DIGIT), and full-time = partial-time time-offset. The time-offset is "Z" or a numeric (+/-)HH:MM value.
The date-time wire encoding uses fixed-width fields: date-fullyear (4DIGIT), date-month (2DIGIT, 01-12), date-mday (2DIGIT), time-hour (2DIGIT, 00-23), time-minute (2DIGIT, 00-59), time-second (2DIGIT, 00-60), optional time-secfrac ("." 1*DIGIT), and time-offset ("Z" or ("±") time-hour ":" time-minute). Fields are separated by literal "-", "T", ":", and "+"/"-" characters.
The Internet Date/Time Format is: date-time = full-date 'T' full-time, where full-date = date-fullyear '-' date-month '-' date-mday (4-2-2 digits) and full-time = partial-time time-offset. The 'T' separator and 'Z' offset marker may be upper or lower case.
The Internet Date/Time Format is defined as `date-time = full-date "T" full-time`, where `full-date = date-fullyear "-" date-month "-" date-mday` (YYYY-MM-DD) and `full-time = partial-time time-offset`. The separator "T" and UTC suffix "Z" may be upper or lower case; applications generating this format SHOULD use upper case.
The Internet Date/Time Format is defined by the ABNF production `date-time = full-date "T" full-time`, where `full-date = date-fullyear "-" date-month "-" date-mday` and `full-time = partial-time time-offset`. The "T" separator and all punctuation are mandatory; `time-offset` is either "Z" or a numeric `("+" / "-") time-hour ":" time-minute` value.
The numeric UTC offset time-numoffset is encoded as "+" or "-" followed by time-hour ":" time-minute, representing an integral number of minutes difference from UTC. Non-integral historical offsets cannot be represented exactly and must be rounded to the nearest representable value.
The optional fractional seconds field is encoded as time-secfrac = "." 1*DIGIT, following time-second. It is the only optional element in the format.
The optional `time-secfrac` field is encoded as "." followed by one or more digits, appended immediately after `time-second`. It is the only optional component in the Internet Date/Time Format.
The optional time-secfrac field is '.' followed by one or more digits, providing sub-second precision. The time-second field may be '60' at the end of months containing a leap second (June 30 or December 31), and '58' when a leap second is subtracted.
The partial-time field is time-hour ":" time-minute ":" time-second [time-secfrac], where time-secfrac = "." 1*DIGIT. Fractional seconds are optional and may have any number of digits.
The time component is encoded as time-hour ':' time-minute ':' time-second [time-secfrac], where time-second is 2DIGIT with valid range 00-58, 00-59, or 00-60 depending on leap second rules. The optional time-secfrac is '.' followed by one or more digits.
The time component is `full-time = partial-time time-offset`, where `partial-time = time-hour ":" time-minute ":" time-second [time-secfrac]` and `time-offset = "Z" / ("+" / "-") time-hour ":" time-minute`.
The time-numoffset field encodes a UTC offset as ("+" / "-") time-hour ":" time-minute, representing local time minus UTC. Numeric offsets represent only time zones differing from UTC by an integral number of minutes.
The time offset component is `time-offset = "Z" / time-numoffset`, where `time-numoffset = ("+" / "-") time-hour ":" time-minute`. Numeric offsets represent the difference "local time minus UTC" and are mandatory; alphabetic timezone strings are not permitted.
The time-offset field encodes the UTC relationship as either "Z" (UTC, offset 00:00) or a numeric offset in the form ("±") HH:MM. The offset "-00:00" is reserved to indicate that UTC is known but the local offset is unknown, and is semantically distinct from "+00:00" or "Z".
The time-offset field is either "Z" (UTC) or a numeric offset of the form ('+' / '-') time-hour ':' time-minute, representing local time minus UTC. Alphabetic timezone strings are not permitted.
The time offset field is encoded as time-offset = "Z" / time-numoffset, where time-numoffset = ("+" / "-") time-hour ":" time-minute. Offsets represent local time minus UTC.
The time-offset field is encoded as "Z" for UTC or as a numeric offset time-numoffset = ("+" / "-") time-hour ":" time-minute. Alphabetic timezone abbreviations are not permitted. Numeric offsets represent local time minus UTC.
The time portion is encoded as partial-time = time-hour ':' time-minute ':' time-second [time-secfrac], where time-hour is 2DIGIT (00-23), time-minute is 2DIGIT (00-59), time-second is 2DIGIT (00-60 allowing for leap second), and time-secfrac is '.' followed by one or more digits.
The time-secfrac field is encoded as '.' followed by one or more digits and is optional; it is expected only for applications requiring strict ordering or unusual precision.
The time-second field (2DIGIT) may have value '60' at the end of months in which a positive leap second occurs, and '58' as the minimum when a negative leap second is subtracted. All other times the maximum is '59'.
The `time-second` field (2DIGIT) normally ranges 00–59, but MAY be "60" at the end of a month containing an inserted leap second (e.g., XXXX-06-30T23:59:60Z or XXXX-12-31T23:59:60Z). A subtracted leap second makes the maximum "58".
The time-second field is encoded as 2DIGIT with valid range 00-58, 00-59, or 00-60 depending on leap second rules. The optional time-secfrac field is encoded as "." followed by one or more digits.
The time-second field may have the value "60" at the end of months in which a positive leap second occurs (historically June 30 or December 31, encoded as XXXX-06-30T23:59:60Z or XXXX-12-31T23:59:60Z). For a negative leap second, the maximum value is "58".
The time-second field may take the value "60" only at the end of months in which a leap second occurs (historically June 30 or December 31, represented as XXXX-MM-DDT23:59:60Z). A negative leap second reduces the maximum to "58"; otherwise the maximum is "59".
The UTC offset is encoded as time-offset = 'Z' / time-numoffset, where time-numoffset = ('+' / '-') time-hour ':' time-minute. Numeric offsets represent local time minus UTC.
The year field `date-fullyear` is exactly 4DIGIT (0000–9999). Month is 2DIGIT (01–12), day is 2DIGIT (01–31 depending on month/year), hour is 2DIGIT (00–23), minute is 2DIGIT (00–59), second is 2DIGIT (00–60 to accommodate leap seconds).
Time fields: time-hour = 2DIGIT (00-23), time-minute = 2DIGIT (00-59), time-second = 2DIGIT (00-58/59/60 based on leap second rules), with optional time-secfrac = "." 1*DIGIT for fractional seconds.
time-offset is either 'Z' (UTC) or time-numoffset = ('+' / '-') time-hour ':' time-minute. Numeric offsets represent local time minus UTC, so 18:50:00-04:00 equals 22:50:00Z.
Time offset is encoded as time-offset = "Z" / time-numoffset, where time-numoffset = ("+" / "-") time-hour ":" time-minute. Numeric offsets represent local time minus UTC.
time-offset is encoded as 'Z' (UTC) or a numeric offset of the form ('+'/'-') time-hour ':' time-minute, representing local time minus UTC. Alphabetic timezone abbreviations are not used.
time-offset = "Z" / time-numoffset, where time-numoffset = ("+" / "-") time-hour ":" time-minute. The suffix "Z" denotes UTC offset of 00:00; numeric offsets represent local time minus UTC.
time-secfrac = "." 1*DIGIT; fractional seconds are optional and may have any number of digits. This element is expected to be used only by applications requiring strict ordering or unusual precision.
time-secfrac = "." 1*DIGIT provides optional fractional seconds. time-second may take the value "60" at the end of months in which a positive leap second occurs, and "58" if a leap second is subtracted.
time-secfrac is an optional field encoded as a period "." followed by one or more decimal digits, enabling sub-second precision. It is expected to be used only by applications requiring strict ordering or unusual precision.
time-second = 2DIGIT with range 00-58, 00-59, or 00-60 depending on leap second rules. The value "60" is permitted only at the end of months in which a leap second occurs (historically June or December); a subtracted leap second makes the maximum "58".
time-second is 2DIGIT with normal maximum of "59", but may be "60" at the end of months in which a positive leap second occurs (historically June 30 or December 31), and maximum is "58" when a negative leap second is subtracted.
time-second is encoded as 2DIGIT with a range of 00–58, 00–59, or 00–60 depending on leap second rules. The value '60' is permitted only at the end of a month in which a leap second occurs (e.g., XXXX-06-30T23:59:60Z or XXXX-12-31T23:59:60Z).