Route86: A Compact Context-Dependent Timestamp Format

Status of This Memo

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

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.¶

Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."¶

This Internet-Draft will expire on 25 February 2027.¶

Copyright Notice

Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved.¶

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document.¶

Table of Contents

1. Introduction

Conventional textual timestamps can be large relative to the payload of constrained transports. Route86 defines a six-character representation that deliberately exchanges universal self-description for compactness.¶

Interpretation requires a reference date known to both encoder and decoder. That reference date is external to the six-character value and may be fixed by an application profile, derived from registration context, or otherwise selected by the communicating parties.¶

Route86 is not a replacement for a general Internet timestamp format. It is intended for contexts in which compactness, a shared reference context, and approximately minute-scale time resolution are acceptable.¶

2. Requirements Language

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.¶

3. Timestamp Format

A canonical Route86 timestamp consists of exactly six ASCII characters:¶

DDDBBB

DDD is the calendar-day component. BBB is the time-of-day component. No separator occurs between them.¶

The syntax is described using ABNF [RFC5234]:¶

route86        = day-component beat-component
day-component = 3base36
beat-component = 3DIGIT
base36         = DIGIT / %x41-5A

The base36 rule admits only ASCII digits and uppercase ASCII letters A through Z. Thus the ABNF describes canonical values only.¶

4. Temporal Reference and BMT Normalization

Route86 evaluates both the calendar day and the time of day in a single common reference offset. This document defines that offset as UTC+01:00, corresponding to Biel Mean Time (BMT) as used by Internet Time [SWATCH].¶

BMT in Route86 is a fixed offset. Daylight-saving time is not applied.¶

An encoder receiving an instant expressed in another offset MUST first convert that instant to UTC+01:00. The BMT civil date produced by that conversion is used for DDD, and the BMT time of day from the same conversion is used for BBB.¶

If an input value does not identify an absolute instant, for example because it contains a local clock time without an offset or equivalent timezone context, an application profile MUST supply the missing context before Route86 encoding.¶

5. Reference Date

The Route86 calendar component is relative to a reference date that is external to the six-character timestamp. A receiver MUST know the applicable reference date before interpreting DDD.¶

The reference date is a civil date in the proleptic Gregorian calendar as observed in BMT. It has no time-of-day component.¶

This document uses 1970-01-01 as the reference date in examples. Applications MAY use another reference date.¶

The reference date itself has a day difference of zero and therefore encodes as AAA. Calendar-day counting is not inclusive.¶

6. Calendar-Day Component

Let target_date be the BMT civil date obtained after the normalization in Section 4. Let reference_date be the shared Route86 reference date.¶

The signed calendar-day difference is:¶

day_delta = target_date - reference_date

The subtraction is the difference in proleptic-Gregorian ordinal dates. Consequently, the reference date has day_delta = 0, the immediately preceding date has day_delta = -1, and the immediately following date has day_delta = 1.¶

Route86 then applies the decimal offset 13330:¶

route86_day = day_delta + 13330

The value 13330 is chosen because:¶

AAA(base36) = 13330(decimal)

route86_day MUST be in the inclusive range 0 through 46655. Values outside that range are not representable by this version of Route86 and MUST be rejected.¶

The corresponding representable day_delta range is therefore -13330 through +33325 days.¶

The integer route86_day is encoded in Base36 using the alphabet:¶

0123456789ABCDEFGHIJKLMNOPQRSTUVWXYZ

The result MUST be left-padded with 0 characters to exactly three characters. Encoders MUST emit uppercase ASCII letters.¶

7. Time-of-Day Component

Route86 divides each nominal BMT day into 1000 equal intervals. Each interval is 86.4 seconds long.¶

Let s be the exact number of elapsed seconds since BMT midnight, including any fractional part, with:¶

0 <= s < 86400

The beat number is:¶

beat = floor(s * 1000 / 86400)

This is equivalent to floor(s / 86.4). The mathematical floor operation is normative. Implementations SHOULD avoid binary floating-point boundary errors, for example by using integer or rational arithmetic when the source timestamp provides subsecond precision.¶

The result is an integer in the range 0 through 999 and MUST be encoded as exactly three decimal digits, left-padded with zeroes as necessary.¶

0   -> 000
7   -> 007
42  -> 042
382 -> 382
999 -> 999

The commercial @ notation associated with Internet Time is not part of Route86.¶

8. Encoding Algorithm

Given an absolute input instant and a shared reference date, an encoder performs the following steps:¶

1. Convert the input instant to the fixed offset UTC+01:00 (BMT).¶
2. Extract the BMT civil date and the exact elapsed seconds since BMT midnight.¶
3. Compute day_delta as the BMT target date minus the reference date.¶
4. Compute route86_day = day_delta + 13330. Reject the input if the value is outside 0 through 46655.¶
5. Encode route86_day as three uppercase Base36 characters, left-padding with 0 when needed.¶
6. Compute beat = floor(s * 1000 / 86400).¶
7. Encode beat as three decimal digits, left-padding with 0 when needed.¶
8. Concatenate the two components without a separator.¶

9. Decoding Algorithm

Given a canonical Route86 value and the applicable reference date, a decoder performs the following steps:¶

1. Validate the six-character grammar in Section 3.¶
2. Decode DDD as an unsigned Base36 integer route86_day.¶
3. Compute day_delta = route86_day - 13330.¶
4. Add day_delta Gregorian calendar days to the reference date to obtain the BMT civil date.¶
5. Decode BBB as decimal integer beat.¶
6. Interpret the time component as the half-open interval beginning at beat * 86.4 seconds after BMT midnight and ending at (beat + 1) * 86.4 seconds after BMT midnight.¶

For beat = 999, the end of the half-open interval is the following BMT midnight.¶

Route86 does not define a representative point within the decoded interval. An application that needs one, such as the interval start or midpoint, MUST define that convention separately.¶

10. Canonical Representation

A canonical Route86 timestamp:¶

• MUST contain exactly six ASCII characters;¶
• MUST contain three Base36 characters followed by three decimal digits;¶
• MUST use uppercase letters in the Base36 component;¶
• MUST NOT contain whitespace or separators;¶
• MUST NOT contain an @ character; and¶
• SHOULD be transported and stored as an opaque six-character string.¶

Protocol decoders MUST reject characters outside the grammar. User-interface implementations MAY accept lowercase letters for convenience, but such input is non-canonical and MUST be converted to uppercase before storage, comparison, or protocol use.¶

The following value is canonical:¶

Q8S382

The following values are not canonical:¶

q8s382
Q8S@382
Q8S-382
Q8S 382

11. Test Vectors

This section is normative with respect to the arithmetic demonstrated by the vectors.¶

Reference date:      1970-01-01
Input instant:       2026-08-17T10:10:10+02:00
BMT instant:         2026-08-17T09:10:10+01:00
day_delta:           20682
route86_day:         34012
DDD:                 Q8S
BBB:                 382
Route86 timestamp:   Q8S382
Encoded length:      6 octets

12. Use in Message Entities

A Route86 timestamp MAY be used as the temporal component of a message entity or identifier.¶

A Route86 value MUST NOT be assumed to be globally unique. Applications requiring uniqueness MUST combine it with additional context, such as an origin identifier, recipient identifier, nonce, sequence value, or cryptographic identifier.¶

A tuple consisting of origin context, recipient context, and Route86 value is one possible application-level construction, but this document does not standardize such a tuple.¶

13. Precision, Intervals, and Ordering

The time-of-day component has a nominal resolution of 86.4 seconds. Route86 MUST NOT be used as the sole representation where second-level timestamp precision is required.¶

Within one shared reference-date context, canonical Route86 strings sort chronologically in ascending ASCII lexicographic order. This follows from the fixed-width Base36 day component, the value order of the canonical Base36 alphabet, and the fixed-width decimal beat component.¶

This ordering property does not apply across values interpreted with different reference dates.¶

14. Application Profiles and Salted Reference Dates

An application profile MAY select a fixed reference date, negotiate a reference date, derive it from registration state, or use a salted reference date.¶

A profile that does not use a universally fixed reference date SHOULD specify how the date is established, how long it remains valid, and what happens when a target date falls outside the representable Route86 range.¶

Policies that restrict the age or placement of a reference date are application-level rules and are not part of the Route86 wire format.¶

15. Security Considerations

Route86 is an encoding format. It provides no confidentiality, integrity, authentication, authorization, or replay protection.¶

A salted reference date can obscure casual interpretation of a timestamp, but it MUST NOT be treated as a cryptographic secret or security boundary. Candidate date ranges are commonly small enough to permit exhaustive guessing, especially when an attacker has approximate knowledge of the encoded date.¶

Protocols requiring authenticated or integrity-protected timestamps MUST provide those properties independently of Route86.¶

Implementations comparing Route86 values from untrusted sources MUST ensure that the same reference-date context applies before relying on chronological ordering.¶

16. IANA Considerations

This document has no IANA actions.¶

Appendix A. Changes from -00

• Clarified that the reference date itself has day_delta = 0 and encodes as AAA.¶
• Defined calendar arithmetic explicitly and established the full representable range 000 through ZZZ.¶
• Specified that both timestamp components are derived after normalization to fixed UTC+01:00 BMT.¶
• Defined the beat calculation using normative mathematical floor semantics.¶
• Specified leap-second behavior.¶
• Added ABNF, explicit encoding and decoding algorithms, and normative test vectors.¶
• Corrected the complete example from Q8T340 to Q8S382.¶
• Clarified that canonical values sort chronologically only within a shared reference-date context.¶
• Separated application-profile policy from the Route86 wire format.¶
• Expanded security considerations and references.¶
• Updated the author's email address.¶

Author's Address