Dorfzwockel

dorfzwockel@not4bflu55.de

This document specifies Route86, a compact textual timestamp format for constrained message transports. A Route86 value consists of a three-character Base36 calendar-day component and a three-digit decimal time-of-day component. The canonical representation occupies exactly six ASCII characters. The calendar component is interpreted relative to an external reference date. The reference date itself encodes as AAA. The time-of-day component divides a fixed BMT day, defined here as UTC+01:00 without daylight-saving adjustment, into 1000 intervals of 86.4 seconds.

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.

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.

Timestamp Format A canonical Route86 timestamp consists of exactly six ASCII characters: DDD is the calendar-day component. BBB is the time-of-day component. No separator occurs between them. The syntax is described using ABNF : The base36 rule admits only ASCII digits and uppercase ASCII letters A through Z. Thus the ABNF describes canonical values only.

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

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.

Calendar-Day Component Let target_date be the BMT civil date obtained after the normalization in . Let reference_date be the shared Route86 reference date. The signed calendar-day difference is: 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: The value 13330 is chosen because: 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: The result MUST be left-padded with 0 characters to exactly three characters. Encoders MUST emit uppercase ASCII letters.

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: The beat number is: 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. 000 7 -> 007 42 -> 042 382 -> 382 999 -> 999 ]]> The commercial @ notation associated with Internet Time is not part of Route86.

Leap Seconds Route86 models a nominal day as exactly 86400 seconds and has no distinct lexical representation for a leap-second label such as 23:59:60. An encoder presented with a timestamp containing a leap-second label MUST NOT encode that label directly. The application MAY normalize such an input before Route86 encoding if its profile defines an unambiguous mapping. Applications that need to preserve leap-second identity MUST NOT rely on Route86 as their sole timestamp representation.

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.

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

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: The following values are not canonical:

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

Calendar-Day Vectors Using the reference date 1970-01-01: Calendar-day vectors

Target BMT date	day_delta	Decimal value	DDD
1933-07-04	-13330	0	000
1969-12-31	-1	13329	AA9
1970-01-01	0	13330	AAA
1970-01-02	1	13331	AAB
2026-08-17	20682	34012	Q8S
2061-03-29	33325	46655	ZZZ

Time-of-Day Vectors BMT beat vectors

BMT time	Elapsed seconds	BBB
00:00:00	0	000
00:01:26.399	86.399	000
00:01:26.400	86.4	001
09:10:10	33010	382
23:59:59	86399	999

Complete Example With reference date 1970-01-01, the instant 2026-08-17T10:10:10+02:00 first normalizes to 2026-08-17T09:10:10+01:00 BMT.

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.

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.

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.

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.

IANA Considerations This document has no IANA actions.

Normative References Informative References Swatch AG Defines the 1000-beat day and identifies BMT as the reference for Internet Time.

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.