This document maps the existing IETF standards for time representation and distribution, identifies the gap for solar time, and describes what TimeNow has built that could serve as the reference implementation for filling it.
The Internet's time infrastructure is built in layers, each standardised by the IETF. All of them assume civil time — politically defined UTC offsets. None of them represent solar time.
RFC 5905 — Network Time Protocol Version 4 (NTPv4) (June 2010, Standards Track)
NTP synchronises device clocks to UTC with sub-millisecond accuracy over the Internet. It is the universal foundation: every device that knows what time it is, knows via NTP or GPS (which is itself UTC-derived). Accuracy on a well-configured LAN: tens of microseconds. On a public Internet pool server: 1–50 ms.
Relevance: Our IoT devices need NTP or GPS-PPS to establish the UTC reference from which solar time is derived. The accuracy is more than sufficient — solar time changes at 4 min per degree of longitude, and 1 arcminute of solar position error corresponds to ~4 seconds of time error. NTP gives us better than 50 ms.
RFC 3339 — Date and Time on the Internet: Timestamps (July 2002, Informational)
Defines the ubiquitous format: 2026-04-13T14:01:32Z. The Z suffix means
UTC. Numeric offsets like +02:00 mean civil local time. There is no field
for solar time, geographic coordinates, or biological time.
RFC 9557 — Date and Time on the Internet: Timestamps with Additional Information (April 2024, Standards Track) — updates RFC 3339
This is the most important recent development. RFC 9557 defines the Internet Extended Date/Time Format (IXDTF) — a suffix syntax for attaching structured metadata to an RFC 3339 timestamp:
2026-04-13T14:01:32Z[Europe/Madrid]
2026-04-13T14:01:32Z[Europe/Madrid][u-ca=gregory]
The bracket suffix is an IANA-registered extension key–value pair. The working
group explicitly states the format is designed to be extensible to future
needs. Crucially, RFC 9557 also updates RFC 3339 to clarify that the Z suffix
no longer implies UTC is the "preferred reference point for the specified
time" — acknowledging that the UTC instant and the human-local interpretation
are separate concerns.
This is the right hook for solar time.
RFC 9636 — The Time Zone Information Format (TZif) (October 2024, Standards Track) — obsoletes RFC 8536
Specifies the binary format of IANA tzdata files (/usr/share/zoneinfo/).
These files encode: UTC offsets, DST transition history and rules, timezone
identifiers. Every UNIX system, JVM, and browser uses TZif files. The format
encodes political time.
Relevance: Our timeshape library reads TZif-derived data. Solar time does
not need TZif — it is a pure mathematical function of longitude and UTC, with
no transition table required.
RFC 7808 — Time Zone Data Distribution Service (TZDIST) (March 2016, Proposed Standard)
Defines a scalable HTTP service for distributing IANA tzdata to devices. Its charter explicitly mentions IoT:
"The protocol must scale to vast numbers of clients, such as the potential 'internet of things' devices, as well as to today's desktop computers and servers."
The working group (tzdist, now concluded) was also motivated by the problem that DST rule changes happen with days of notice, but OS timezone updates trail by weeks. TZDIST solves this by making timezone data a service, not an OS package.
Relevance: For solar time, this problem does not exist. Solar time has no political transitions. The mathematics are fixed by astronomy — VSOP87 will be accurate for centuries. An IoT device with GPS coordinates and NTP sync needs no distribution service for solar time. This is a structural advantage.
RFC 4833 — Timezone Options for DHCP (April 2007, Proposed Standard)
Allows a DHCP server to push a timezone identifier (Europe/Madrid) to a
device at network join time. A device with no local configuration can learn
its civil timezone from the network.
Relevance: The same DHCP option could be extended to carry GPS coordinates (or a solar time offset) to devices that cannot determine their own location. However, GPS is the better path for IoT since it gives continuous, precise coordinates.
RFC 6557 / BCP 175 — Procedures for Maintaining the Time Zone Database (February 2012, Best Current Practice)
Defines who controls the IANA timezone database, how changes are submitted, and how disputes are resolved. The maintainer is Paul Eggert at UCLA.
Relevance: Solar time has no database to maintain. This is not a weakness — it is the point. A function of longitude and UTC requires no political governance.
Swatch proposed .beat time — 1000 beats per day, no time zones, anchored to
Biel/Bienne, Switzerland (UTC+1). Example: @857 means 857/1000 of the day
has elapsed since midnight BMT.
Why it failed:
- Still an arbitrary anchor (Swatch headquarters)
- Not based on the Sun — just moved the meridian
- No relationship to biological daylight
- No scientific or standards body support
What it got right: The idea that a single continuous global time reference is better than 400+ civil zones. It was the diagnosis without the solution.
Several computer scientists (Coordinated Universal Time advocates) have
proposed simply using UTC everywhere, displaying 14:00 UTC instead of
16:00 CET. This solves the coordination problem perfectly but ignores the
biological problem entirely. A person in Madrid would wake up at 07:00 UTC
in winter — which happens to be civil 08:00 CET — still 2 hours before their
sun.
What it gets right: Simplifies coordination.
What it misses: The problem is not coordination. The problem is the
mismatch between what the clock says and where the Sun is.
A systematic search of the RFC editor database and IETF datatracker finds zero RFCs addressing:
- True solar time representation
- Solar time calculation protocols
- Location-based continuous time
- Civil-vs-solar offset in timestamps
- Device-to-device solar time sharing
This is not an oversight. The IETF standardises what the Internet needs to interoperate. Before a network of devices computing and sharing solar time exists, there is no interoperability problem to solve.
TimeNow creates the problem worth standardising.
TimeNow is the first implementation of a complete solar time layer on top of the civil time infrastructure. It maps directly onto the RFC stack.
SpaCalculator.scala implements the NREL Solar Position Algorithm (Reda &
Andreas 2004) — VSOP87 truncated series for Earth's heliocentric position,
63-term IAU 1980 nutation, aberration correction. Accuracy: ±0.0003°.
HighPrecisionSolar.scala wires it to Orekit 13 for ΔT (TT−UT1 from IERS
EOP data, updated weekly from USNO). This is the precision layer below NTP:
where NTP gives milliseconds, IERS EOP gives the sub-second Earth rotation
correction that makes the difference between ±1 arcminute and ±0.0003°.
Input: (latitude, longitude, UTC instant) — all available from GPS + NTP.
Output: local solar time, solar noon, civil-vs-solar offset, sun elevation and
azimuth, day boundaries.
The API returns UTC timestamps (computed_at_utc, sunrise_utc,
solar_noon_utc) in RFC 3339 format. It also returns local_solar_time as a
HH:MM:SS string and civil_solar_offset_min as a number.
The natural next step, following RFC 9557 IXDTF, is a proposed suffix key:
2026-04-13T12:00:52Z[solar/51.5,-0.1]
Where:
2026-04-13T12:00:52Zis the UTC instant (RFC 3339 — coordination layer)[solar/51.5,-0.1]is the IXDTF suffix carrying geographic context
Decoded: "At this UTC instant, a device at latitude 51.5°N, longitude 0.1°W was experiencing local solar time 12:00:52." UTC is preserved exactly. The solar interpretation is attached, not replacing.
This format has not been proposed to IETF. TimeNow is its reference implementation.
GET /world/deviation-map returns a 2° global grid of
civil_utc_offset − longitude/15 — the structural misalignment baked into
every civil timezone by the political decisions maintained via RFC 6557/BCP175.
The map makes the governance failure visible: deep red over western China and Spain, caused not by physics but by the decision to apply a single UTC offset across a politically defined region.
OrekitDataLoader fetches finals2000A.all from USNO weekly — the same data
source that IERS publishes and that NTP stratum-1 servers use for UTC
corrections. This gives ΔT (TT−UT1) accurate to published IERS values.
The GET /health endpoint exposes iers.is_fresh, iers.age_hours, and
iers.last_updated — a machine-readable data-freshness indicator that any
monitoring system can consume.
GET /solar?lat=X&lng=Y&dt=ISO8601 is stateless, deterministic, and requires
only three inputs that any GPS+NTP device can provide without human
configuration. It returns a complete solar time result in under 5 ms.
The A2ARoutes stub implements device-to-device message passing. This is the
foundation for the peer sharing protocol — the layer above the calculation
that allows devices to announce their solar time and receive others'.
A machine-readable API schema following OpenAPI 3.0.3. This is the starting point for a formal protocol specification, should an IETF working group ever be formed around solar time distribution.
Building on RFC 9557's extension mechanism, we propose the following suffix key for solar time annotation of UTC timestamps:
time-zone-annotation =/ "[solar/" lat-value "," lng-value "]"
lat-value = ["-"] 1*2DIGIT ["." 1*6DIGIT]
lng-value = ["-"] 1*3DIGIT ["." 1*6DIGIT]
; Solar noon at London on 13 April 2026
2026-04-13T12:00:52Z[solar/51.5,-0.1]
; Solar noon at Kashgar — note UTC+8 civil time would show 19:54
2026-04-13T11:54:18Z[solar/39.47,75.98]
; Same instant, Shanghai — UTC+8 civil shows 19:54 but solar shows 19:54 too
; (Shanghai is near-aligned with UTC+8)
2026-04-13T11:54:18Z[solar/31.22,121.46]
The Kashgar and Shanghai examples share the same UTC instant but different
solar contexts. A system displaying the [solar/...] suffix would show:
Kashgar: solar 11:54 — civil 19:54 — offset: +8h 00m ahead of sun
Shanghai: solar 11:54 — civil 19:54 — offset: +0h 06m (near-aligned)
- The UTC instant is authoritative. The
[solar/lat,lng]suffix is informational. - A consumer that does not understand the suffix MUST ignore it (per RFC 9557 §3.3 elective consumption).
- A consumer that does understand it MAY compute
civil_solar_offset_minfrom the suffix coordinates and the UTC offset in the base timestamp. - The suffix coordinates SHOULD be the GPS coordinates of the device or location that generated the timestamp.
- The suffix does NOT change the instant represented. It adds geographic context to a fixed UTC instant.
- IoT minimal mode — strip to
(lat, lng, UTC) → solar_time, 128 MB RAM - GPS NMEA input — auto-populate coordinates from serial port
- Peer sharing protocol — devices broadcast
[solar/lat,lng]-tagged UTC timestamps over mDNS/local HTTP; others receive and display the solar time at each peer's location - Offline IERS bundle — static EOP data baked in for air-gapped devices
- Register
solaras an IXDTF suffix key with IANA (per RFC 9557 §3.2) - Define the calculation normative reference (NREL SPA / VSOP87) in an Internet-Draft
- Propose a lightweight peer discovery protocol (extending TZDIST patterns from RFC 7808 for local networks)
| Document | URL |
|---|---|
| RFC 3339 | https://www.rfc-editor.org/rfc/rfc3339 |
| RFC 4833 | https://www.rfc-editor.org/rfc/rfc4833 |
| RFC 5905 (NTPv4) | https://www.rfc-editor.org/rfc/rfc5905 |
| RFC 6557 / BCP 175 | https://www.rfc-editor.org/rfc/rfc6557 |
| RFC 7808 (TZDIST) | https://www.rfc-editor.org/rfc/rfc7808 |
| RFC 9557 (IXDTF) | https://www.rfc-editor.org/rfc/rfc9557 |
| RFC 9636 (TZif) | https://www.rfc-editor.org/rfc/rfc9636 |
| NREL SPA (Reda & Andreas 2004) | https://www.nrel.gov/docs/fy08osti/34302.pdf |
| IERS Conventions 2010 | https://www.iers.org/IERS/EN/Publications/TechnicalNotes/tn36.html |
| IERS finals2000A.all | https://maia.usno.navy.mil/ser7/finals2000A.all |
| IANA Time Zone Database | https://www.iana.org/time-zones |
| VSOP87 (Bretagnon & Francou 1988) | https://ui.adsabs.harvard.edu/abs/1988A%26A...202..309B |