Sort strings only under compatible conventions
05Consistently formatted timestamp strings can sort chronologically. Mixed offsets or fractional widths break the shortcut even when the timestamps are valid.
Pad .1Z to .10Z. Now .10Z sorts before .11Z and matches time order. This fixes the illustrated pair, not every leap-second, clock-trust or offset-context problem.
Source for this drawing: RFC 3339 · Read RFC section 5.1 ↗
New to this? Start hereA quick picture + helpful background
A message needs an address.
Think of a packet as a small addressed envelope. Devices pass it onward; transport protocols decide what delivery promises an application gets.
Start with this guide; no earlier guide is needed for the overview.
These pictures are analogies to help you learn. The linked RFC explains the actual rules.
Terms in this drawing
Related RFCs and changes
“Updates” changes part of an earlier RFC. “Obsoletes” replaces it. This list shows selected related documents.
Compare instants when spelling conventions differ.
- For string sorting to imply time order, use the same time zone and offset spelling, the same number of fractional digits, and consistent punctuation and case. Verified editorial erratum293 clarifies optional punctuation or white space can break the property.
- Mixed offsets can reverse lexical versus chronological order. Different fractional lengths can do so too: .11Z sorts before .1Z as text, although 0.1 seconds is earlier.
- For the shown ordinary timestamps, normalize the instant and use a common lossless fractional width before string sorting. Preserve original offset context separately when needed. A syntactically valid timestamp is not proof that a clock or sender is trustworthy.
Normalizing for an application’s sorting convention is a chosen strategy, not a requirement that all valid inputs use Z or two fractional digits. Padding .1 to .10 preserves this example exactly; truncating arbitrary precision could lose information. New Internet clients SHOULD be prepared to display dates suitably for the user’s locality. This RFC does not require a specific storage format, authenticate timestamps, or make an offset a time-zone rule set.
Read the RFC section ↗