T32 · Draft 0.3 · Participation

Participate

T32 is a draft. Before it can become a standard, people other than its author need to read it, build it and report what's wrong with it. This page explains how to take part and what happens next.

1Where the specification stands

Draft 0.1 2026-10-30 First public draft.
Draft 0.2 2026-10-31 Complete enough to implement. Public review opened.
Draft 0.3 2026-11-01 · now Fixes from the first review.
Review Open Open questions settled, and three implementations passing.
Version 1.0 After 60 days Core rules fixed. Stamps keep their meaning.
Working group With 1.0 A group of implementers and reviewers takes over.

The draft is complete enough to implement and test against, but it isn't final. Any part may change before version 1.0. Every change is made in public, with the reason for it, and listed in Appendix D of the specification.

2Ways to take part

Question it: Read the specification as if you had to implement it from the text alone. If anything is unclear, missing or wrong, report it. That includes any sentence two careful readers could take to mean different things.
Weigh in: The questions below haven't been decided yet. What you've seen in your own systems is the most useful input. Post it in Discussions.
Implement it: Load the conformance vectors, make them pass in your language, and add your implementation to the list. Version 1.0 needs at least three implementations written independently.
Help govern it: A working group made up of active implementers and reviewers will take over the project. If you'd like to be part of it, say so in Discussions. Knowing who is interested helps decide how the group is set up.

3Open questions

These are the questions the editor considers open before version 1.0. Each states the current position and the kind of evidence that would change it. Discussion of any of them is welcome, in the Discussions of the specification's repository.

C.1 The name. "T32" is also the name of Arm's 32-bit Thumb instruction set and the common name of Lauterbach's TRACE32 debugger. The current position is to keep the name, since the contexts rarely meet and the name says what the format is: T for time, 32 for its radix. Evidence of real confusion, or a better name, would reopen it.

C.2 The epoch. T32 counts from 2000-01-01T00:00:00 TAI. Alternatives considered were J2000 (2000-01-01T12:00:00 TT), which suits astronomy, and 1972-01-01, when UTC's offset from TAI became whole seconds. The current position favours a round instant in the scale T32 counts. Since the epoch fixes every stamp, this question closes at version 1.0.

C.3 Before 1961. Labels before 1961 are read as Universal Time, which keeps stamps stable but makes elapsed time non-physical across centuries. The alternative is to apply a ΔT model, which is physical but changes stamps whenever the model is revised. The current position favours stability. Users of historical or astronomical data are invited to say which they would rather have. The reading of these labels is frozen at version 1.0, so this question closes then.

C.4 The resolution rule. An encoder may use the length whose unit is nearest its source's resolution on a logarithmic scale ( $u (n) > r / \sqrt{32}$ ), so a stamp can claim up to $\sqrt{32}$ (about 5.7) times more resolution than its source has. The stricter alternative is the longest length whose unit is no finer than the source, which gives 9 for a millisecond clock instead of 10. The current position prefers the familiar lengths 8, 10, 12 and 14 for seconds, milliseconds, microseconds and nanoseconds.

C.5 Letter case. Canonical stamps are uppercase. Lowercase reads better in URLs and file names, and some systems fold case. Since parsing is case-insensitive, the question is only which form is canonical. The current position is uppercase, as in Crockford base32.

C.6 A human rendering. The specification defines a display form for stamps, but not how to show a stamp's interval to people in their own calendar and time zone. A recommended rendering could make stamps easier to adopt in interfaces. The question is whether it belongs in this document or in a companion one.

C.7 Identifiers and registration. T32 defines no URI scheme, media type or registered tag. Candidates include a suffix tag under RFC 9557 and a URN namespace. Registration would follow version 1.0, and only if implementers ask for it.

C.8 Other time scales. TAI suits clocks on Earth. Lunar and Martian time scales are being defined, and a T32 profile for one of them would need its own epoch and conversion. The current position is to leave the format TAI-only and to define profiles, if any, in separate documents.

4Implementations

Implementations of T32 known to the editor. An implementation conforms to a class when it passes every vector for that class in vectors/t32-vectors.json; the classes are defined in the specification under Conventions and conformance.

To add yours, open a pull request that adds a row, with a link to where it runs the vectors. Partial implementations are welcome: say which classes they cover.

Implementation	Language	Classes	Vectors	Maintainer	Notes
`t32` (source)	Rust	All	All pass from 0.3.0	@oddurs	Reference implementation. No required dependencies; optional serde.
`t32.ts`	TypeScript	All	All pass	@oddurs	One file, BigInt arithmetic. Runs the site's playground.
`oracle.py`	Python	Encoder, decoder, converter, parser	Generates them	@oddurs	Exact rational arithmetic, written from the text. A checking tool, not a library.

Wanted#

Independent implementations are what take the specification to version 1.0 (see GOVERNANCE.md). These would be especially welcome, each by an author other than the editor:

Go, Python, Java or Kotlin, C or C++, Swift, Zig. A library with parsing, encoding and decoding.
PostgreSQL. A type or a set of functions for T32-n columns, with range queries.
SQLite. A loadable extension.
Command-line tools. A converter in the spirit of date.

If you start one, say so in Discussions, so that others can join rather than duplicate.

5How decisions are made

T32 is an open specification. This document describes how it changes, who decides, and how it is meant to grow from one editor's draft into a standard maintained by the people who use it.

Principles#

The specification is the product. Code, the site and the vectors serve the text. Where they disagree, the text decides, and the disagreement is a defect to fix.
Changes are made in the open. Every change to normative text is proposed publicly, carries its reason, and is recorded in Appendix D of the specification.
Rough consensus and running code. Decisions follow the weight of argument, not the count of votes, and a proposal is stronger for an implementation and vectors that show it works.
Stamps keep their meaning. A stamp, once written, always refers to the same interval of time. Proposals that would change the meaning of existing stamps are out of scope after version 1.0.

Roles#

Editor. Oddur Sigurdsson (@oddurs) edits the specification. The editor keeps the text coherent, judges consensus, merges changes and records them. The editor may decline a proposal, and does so in writing, with reasons, on the proposal itself.

Contributors. Anyone who reports a defect, proposes a change, reviews a proposal, writes an implementation or adds vectors. Contribution needs no permission.

Implementers. Authors of the implementations listed in IMPLEMENTATIONS.md. Their experience carries particular weight, because they find what the text leaves unsaid.

How a change is made#

Kind	Examples	Where	How it is decided
Editorial	Typos, clearer wording, examples	Pull request	The editor merges it
Erratum	Text and vectors disagree; a rule can be read two ways	Issue, then pull request	The editor fixes it, noting the fix in Appendix D
Substantive	New rules, changed behaviour, anything in Appendix C	Discussion, then a proposal	Rough consensus, judged by the editor, after a review period

A substantive proposal states the problem, the change to the text, its effect on existing stamps and implementations, and new or changed vectors. It is open for review for at least two weeks before a decision, and the decision is written on the proposal with its reasons. A decision can be revisited when new evidence arrives.

Versions#

Drafts (0.x). Any part may change. Each draft is tagged, dated and listed in Appendix D.
Version 1.0. Definitions, Encoding, Decoding and the grammar are frozen. Later 1.x versions may add, for example rows in Appendix A or new profiles, but may not change what an existing stamp means.

Version 1.0 will be published when all of the following hold:

Every question in Appendix C has a recorded decision.
At least three independent implementations, in at least two languages and by different authors, pass the full vectors file.
A public review period of at least 60 days has passed since the last substantive change, announced in advance.
No erratum is open.

Toward a working group#

A single editor works for a draft, but a standard that people rely on shouldn't depend on one person. The plan is for T32 to be run by a group.

When version 1.0 is published, or earlier if there is enough interest, a T32 Working Group will be formed by a short public charter covering its scope, membership, decision process and the transfer of the repository to a neutral organisation. Its first members will be drawn from active implementers and reviewers. The editor's role then becomes a role of the group, held by whoever the group chooses.

Beyond that, if T32 sees real use in protocols, the group may take the specification to an established standards body, for example as an IETF Internet-Draft, and maintain it there. The group would make that decision.

If you'd like to take part, say so in Discussions. Knowing who is interested helps decide how the group is set up.

Conduct#

Everyone taking part in the project follows the Code of Conduct.