Making history
in time.

01 / PREMISE

A shared reference timeline

I’m proposing STONE Time so that people, computers, agencies, and eventually planetary systems can refer to a common timeline. A call in Las Vegas, a dispatch in New York, a transaction in Dubai, and a message sent toward Mars can each carry a source timestamp, a normalized reference when available, and a distinct record ID.

A timestamp identifies a time reading. Separate records can share that reading. Each event needs its own stable identity and a link to its source.

02 / METROLOGY

The second, the scale, and the record

Use the SI second, defined through the cesium-133 transition frequency. International Atomic Time (TAI) provides a continuous atomic scale. UTC supports civil coordination. Local civil time and planetary solar time are display conventions with distinct rules.

The prototype displays ISO-format UTC using the browser’s device clock. The proposal for a production format is an explicitly named continuous scale, a versioned epoch, an integer count of subsecond units, and conversion metadata. Epoch, precision, leap-second data, and time-scale policy require review before the format can be declared stable.

Prototype display:  2026-02-10T18:00:00.000Z
Future record:      scale + epoch version + integer ticks
Required metadata:  source, precision, uncertainty, conversion version

Precision describes the reported resolution. Uncertainty describes how closely that value may represent the reference instant. A timestamp with milliseconds can still have unknown clock uncertainty.

03 / STELLAR JOURNEY

Polaris to Earth’s Pacific Rim

Polaris anchors the astronomical identity of the project. The founder’s illustrative 440-light-year value describes a centuries-long light path. The Pacific Rim is the Earth-side observing region. Its location on the surface makes a negligible difference at this scale.

Modeled travel time = distance / c
Tick duration       = modeled travel time / 24
440 Julian years / 24 ≈ 18.333333 Julian years per tick

The 440-light-year input is illustrative. A research release should pin the selected Polaris component, data product, observing epoch, reference frame, distance estimate, method, and uncertainty. CHARA observations and published work using Gaia astrometry are starting points for reviewing those assumptions.

04 / VACUUM DISTANCE

Light-Hour Mode

Here the scale is fixed by the defined vacuum speed of light. Each tick is the distance traversed in 3,600 SI seconds. Twenty-four ticks represent one light-day. Stellar Journey Mode uses a chosen astronomical distance divided into 24 intervals.

c           = 299,792,458 m/s
1 light-hour = 1,079,252,848.8 km ≈ 670.6 million miles
1 light-day  = 25,902,068,371.2 km

05 / REPRODUCIBILITY

Track all 24 divisions

For n elapsed ticks between zero and 24, elapsed fraction is n/24. Multiply that fraction by the modeled duration to get elapsed travel time. The remaining duration is the full model minus elapsed time. When a distance uncertainty is supplied, dividing it by 24 gives the corresponding uncertainty per tick in the same simple model.

The site’s slider is a scenario control. A later version could pin a modeled emission epoch and specify whether each display shows progress since that epoch or the phase of a repeating cycle. Store the model ID, data version, rounding rules, and units so others can reproduce the output.

06 / EARTH

Keep the original clock reading

Preserve source text, any offset or zone provided, the normalized instant, the applicable time-zone rules, and the transformation version. Handle missing offsets, ambiguous times when clocks turn back, and nonexistent local times when clocks move forward. Flag unresolved cases for review.

The clock display uses the browser’s time-zone data, which may vary between devices. A validated ingest service should pin its IANA database release and record the conversion version. The browser’s JavaScript Date representation also skips leap-second labels such as 23:59:60.

07 / MARS

Sols, longitude, and message delays

The Mars lab derives a Mars Sol Date and Airy Mean Time from NASA’s published Mars24 equation, then shifts mean solar time by east longitude. The demonstration uses a fixed TT−UTC offset of 69.184 seconds for dates starting in 2017. The approximation will need an updated leap-second source if the offset changes.

MSD   = (JD(TT) − 2451549.5) / 1.0274912517 + 44796 − 0.0009626
Airy  = 24 × fractional part of MSD
LMST  = (Airy + east longitude / 15) modulo 24
Delay = assumed path length / c

Preserve send time, receive time, and the estimated signal delay as separate values. A mission-grade model needs independently verified clocks, endpoint states at emission and reception, a defined ephemeris, propagation corrections, and an uncertainty budget.

08 / PHYSICS

Compare clocks in a defined frame

Proper time is what a particular clock measures along its trajectory. Coordinate time supplies a convention for comparing distant events. Signal travel time describes the propagation between endpoints. The civil display and stellar cycle are separate representations.

Define the coordinate scale, transformations, frame conventions, and precision target for each application. Document which gravitational and motion effects must be modeled. When two event uncertainty intervals overlap, preserve the ambiguity in their ordering.

09 / IMPLEMENTATION

Eight independently testable modules

1. Time Core. Parse, validate, serialize, and compare reference timestamps.
2. Conversion Engine. Translate supported UTC, TAI, civil, and planetary representations with versioned rules.
3. Stellar Mathematics. Compute modeled light journeys and light-hour distances.
4. Planetary Time. Model sols, longitude conventions, and mission time displays.
5. Signal Delay. Estimate propagation with explicit geometry and model versions.
6. Event Timeline. Keep event identities, original values, version relationships, and source provenance.
7. Verification. Check digests, signatures, authorization, audit histories, and inclusion proofs.
8. Public Display. Show clocks, uncertainty, inputs, and accessible charts for each model.

10 / VERIFICATION

Make changes detectable

A production record should retain its ID, source, reported occurrence, creation and receipt timestamps, authorized signer, clock evidence, version history, record digest, and access history. Corrections should append an auditable version and reference the original.

The demo canonicalizes flat JSON by sorting property names and encodes it as UTF-8. It uses SHA-256 with a 0x00 leaf prefix and a 0x01 branch prefix, duplicating an unpaired final node at each layer. Its root is computed from the fictional bundled dataset. Production commitments would need an independently authenticated root, a cross-language canonicalization specification, key rotation, and externally witnessed history.

Digital signatures can identify a signing key. Authority depends on who controlled the key and what they were authorized to sign. An inclusion proof checks consistency with a commitment. A claim’s factual truth depends on corroborating evidence. Explore limited-disclosure or zero-knowledge proofs only after defining the exact statement, threat model, and privacy requirements.

11 / CIVIC APPLICATION

Call, dispatch, report, referral, service, payment

Preserve every step independently. Original call audio, CAD timestamps, body-camera metadata, reports, referrals, contract amendments, service logs, invoices, payment approvals, and audits can be compared while retaining their distinct sources.

An auditor can follow the record from authorization through invoice, payment, delivery, and verification. Relationships need their own supporting records. Missing, withheld, conflicting, or unverified entries should be visibly distinguished. An apparent discrepancy is a research question and a reason to preserve the underlying records.

12 / RIGHTS AND SECURITY

Protect the people in the records

Design around data minimization, encryption, strong authentication, least privilege, role-based access, independently reviewed permissions, and retention policies. Keep sensitive case material out of public examples and expose only what each authorized verification requires.

Define who can approve a correction, how a disputed entry is marked, what happens when a credential is compromised, how revocations propagate, and when retention limits require deletion. Access policy and audit history need independent oversight and a documented route for challenges.

13 / AUTHORSHIP AND GOVERNANCE

Document the original work and every contribution

Jamie Skeie, also known as Jamie Stone, authored the founding STONE Time proposal. Preserve the original version, record changes and author credit, publish proposed revisions for review, and distinguish official releases from compatible extensions.

The proposed 10% founder economic participation is a starting point for a written agreement. The economic base, terms, licensing, intellectual-property treatment, contributor credits, and approval process remain to be defined. Researchers can challenge calculations and propose improvements through a versioned specification.

14 / DEVELOPMENT

From public prototype to independent review

1. Mathematical specification. Fix units, scale, epoch, cycle definitions, and conversion rules.
2. Clock engine. Establish synchronization monitoring, offset estimation, drift limits, and uncertainty reporting.
3. Stellar engine. Pin a data source and build reproducible inputs and test vectors.
4. Mars engine. Validate solar time, mission clocks, ephemeris-backed signal delay, and coordinate transformations.
5. Cryptographic integrity. Review canonicalization, signatures, Merkle proofs, key controls, and privacy-preserving verification.
6. STONE-911 pilot. Use synthetic or authorized redacted examples with separate event identities.
7. Independent validation. Reproduce equations and test security, fault tolerance, and uncertainty propagation.
8. Governance and licensing. Finalize attribution, contribution, review, and economic agreements.

15 / OPEN TECHNICAL QUESTIONS

Show me the equations and the edge cases.

I’m inviting mathematicians, physicists, astronomers, engineers, metrologists, cryptographers, and aerospace researchers to challenge the proposal. Show how the system behaves when a clock drifts, a signal is delayed, a source changes a timestamp, a signing key is compromised, or two records disagree.

• Check spring-forward, fall-back, half-hour and quarter-hour offsets, date-line rollovers, and leap-second table changes.
• Test uncertainty with unsynchronized, drifting, or temporarily disconnected clocks.
• Compare Mars results against published worked examples under matching time-scale assumptions.
• Attempt duplicate events, delayed receipts, missing parents, altered payloads, compromised keys, and split histories.
• Show how a person can verify a claim while unrelated private information stays protected.

Evidence Before Force. Save Kids With Chalk. Kids Ain’t Cash. The Evidence Earns the Line. Pull the Next Record.

REFERENCE SHELF

Methods and sources

• BIPM SI Brochure and UTC and time metrology.
• IANA Time Zone Database.
• CHARA Array research on Polaris and Polaris orbit study referencing Gaia astrometry.
• NASA GISS Mars24 equations and JPL Horizons.
• RFC 9162 for comparison with production transparency logs. The prototype has its own documented tree rule.