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 18 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 date and time representations can consume a significant portion of a small message. This is particularly relevant to constrained transports in which every octet affects payload capacity.¶

Route86 defines a six-character timestamp designed for such environments. It deliberately trades universal self-description for compactness by assuming that communicating parties share a reference date and the encoding rules defined by this document.¶

For example, using the reference date 1970-01-01, the civil instant 2026-08-17 10:10:10 CEST is represented by:¶

Q8T340

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 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 three-character calendar-day component. BBB is the three-digit time-of-day component.¶

No separator occurs between the components.¶

4. Reference Date

Route86 calendar encoding operates relative to a reference date. The reference date is external context and is not encoded in the six-character timestamp.¶

This document uses 1970-01-01 as its example reference date. This date also contains the Unix epoch, although Route86 does not encode Unix time.¶

An application profile MAY use another reference date. In particular, the reference date MAY be derived from registration information or otherwise salted.¶

A receiver MUST know the applicable reference date before interpreting the calendar-day component.¶

5. Calendar-Day Component

The calendar-day component represents calendar progression relative to the shared reference date.¶

The resulting Route86 day value is encoded as a three-character Base36 value.¶

The Base36 alphabet is:¶

0123456789ABCDEFGHIJKLMNOPQRSTUVWXYZ

Encoders MUST emit uppercase ASCII letters. Decoders SHOULD reject non-canonical lowercase representations.¶

Route86 applies an encoding offset of 13330 decimal before Base36 representation.¶

The precise calendar arithmetic, including treatment of the reference day, MUST be identical at encoder and decoder. Implementations conforming to this version count the reference day according to the Route86 day-numbering algorithm before applying the offset.¶

6. Time-of-Day Component

Route86 divides a day into 1000 decimal units, conventionally called beats.¶

Time-of-day is evaluated relative to UTC+01:00, corresponding to Biel Mean Time (BMT).¶

One beat therefore represents 86.4 SI seconds.¶

The beat number is encoded as exactly three decimal digits. Values smaller than 100 MUST be padded with leading zeroes.¶

7   -> 007
42  -> 042
340 -> 340
999 -> 999

The commercial "@" notation sometimes associated with Internet Time is not part of the Route86 representation.¶

7. 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;¶
• MUST NOT contain whitespace;¶
• MUST NOT contain separators;¶
• MUST NOT contain an "@" character; and¶
• SHOULD be transported as an opaque string.¶

The following is canonical:¶

Q8T340

The following representations are not canonical:¶

q8t340
Q8T@340
Q8T-340
Q8T 340

8. Example

The following example uses a reference date of 1970-01-01.¶

Reference date:   1970-01-01
Civil time:       2026-08-17 10:10:10 CEST
Route86 day:      Q8T
Route86 beat:     340
Route86 timestamp: Q8T340
Encoded length:   6 octets

9. Use in Message Entities

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

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

10. Precision and Ordering

Because one day is divided into 1000 units, the nominal resolution of the time component is 86.4 seconds.¶

Route86 MUST NOT be used where second-level timestamp precision is required.¶

Within a shared Route86 reference context, canonical values can be decoded into their corresponding calendar and time values for chronological comparison.¶

11. Security Considerations

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

A salted reference date can make casual interpretation of a timestamp more difficult, but MUST NOT be treated as a cryptographic secret or security mechanism.¶

Protocols requiring authenticated timestamps MUST provide authentication independently of Route86.¶

12. IANA Considerations

This document has no IANA actions.¶

Author's Address