The mechanics being evaluated
Let A(Y) be the integer civil-day number of the Greenwich UT1 date containing the March equinox associated with Gregorian year Y. Pleroman year Y begins on that date.
Telara length: T(Y) = L(Y) − 336
Months 1–12 have 28 days each. Telara begins at zero-based offset 336 and contains the remainder. Weekdays continue without interruption. For a day offset d < 336, the month is floor(d / 28) + 1 and the date is (d mod 28) + 1; otherwise it is Telara d − 335. Conversion must preserve the underlying civil day in both directions.
These are design rules. The repeated weekday pattern within a year is a mathematical consequence. Neither establishes social usefulness. The specification's PC: notation explicitly identifies a Pleroman date; it is a proposed interchange convention, not a claim of standardized support or a new app input format.
Current implementation choices
Astronomy Engine 2.1.19 searches solar longitude crossings using TT. The calendar explicitly inverts TT = UT1 + ΔT using the library's Espenak–Meeus function, then assigns the Greenwich UT1 date. This is modeled UT1, not a feed of observed IERS Earth-orientation data.
Local civil dates use the selected time zone at midnight. Gregorian conversion is proleptic. The UI's Gregorian input range is astronomical years −9 through 3000 (10 BCE–3000 CE). Internal tests also include Pleroman year −10 as boundary coverage; astronomical year −10 is 11 BCE. Boundary calculations can extend beyond the input range.
The implementation reports an anomaly rather than substituting a year length if a calculated interval is not 365 or 366 days. Selecting an algorithm for this app does not settle the specification's open question of a canonical method for all implementations.
Evidence record
Recorded using v22.16.0 on win32. The downloadable record identifies the tested files by SHA-256 hash and records commands, outputs and reference inputs.
PASSED · INTERNAL CONSISTENCY
1,099,744 dates across 3,011 Pleroman years
test-ut1.cjs passed every date in Pleroman years −10 through 3000 inclusive. It checks round trips, consecutive offsets, month lengths and weekday patterns. All tested years had 365 or 366 days. It also checks 12,044 seasonal events against longitude targets within the same astronomy library, synthetic TT/UT1 midnight cases, a Honolulu/Tokyo date example, and explicit anomaly reporting.
Limit: Shared code and a shared astronomy library can share errors. These checks establish consistency under this implementation, not independent astronomical accuracy or certainty about distant historical and future dates.
Read the full test outputPASSED · REGRESSION CHECKS
78,286 month-boundary round trips
test.cjs checks month endpoints across the same 3,011 years, plus selected full years, BCE transitions, historical-era independence, saved-event migration and selected holiday examples.
Limit: This does not establish that every overlay or user-interface operation has been independently verified, or that historical event hypotheses are true.
Read the full test outputPASSED · WRITTEN EXAMPLES
Nine specification test vectors
The current engine reproduced all nine date pairs in specification v0.1, section 14. Agreement with examples from the same project is a conformance check, not independent validation.
View all nine checked date pairs
| Gregorian reference date | Pleroman date |
|---|---|
| 2025-03-20 | PC:2025-01-01 |
| 2026-03-19 | PC:2025-13-29 |
| 2026-03-20 | PC:2026-01-01 |
| 2026-04-16 | PC:2026-01-28 |
| 2026-04-17 | PC:2026-02-01 |
| 2026-09-19 | PC:2026-07-16 |
| 2026-12-25 | PC:2026-11-01 |
| 2027-03-19 | PC:2026-13-29 |
| 2027-03-20 | PC:2027-01-01 |
PASSED · LIMITED EXTERNAL COMPARISON
Three modern March-equinox dates
The engine's assigned civil dates agree with the U.S. Naval Observatory seasons service for 2025, 2026 and 2027 at time-zone offset zero, with daylight saving disabled.
| Year | USNO reference | Modeled UT1 date | Result |
|---|---|---|---|
| 2025 | 2025-03-20 | 2025-03-20 | Same civil date |
| 2026 | 2026-03-20 | 2026-03-20 | Same civil date |
| 2027 | 2027-03-20 | 2027-03-20 | Same civil date |
Limit: This is a three-date spot check, not validation of the full supported range or exact equinox instants. All three events are hours from midnight. The API documentation uses both UTC and UT1 terminology; no sub-minute equivalence is assumed. Near-midnight cases require explicit time-scale reconciliation.
Source responses are preserved in the evidence download. USNO supplies reference data; it has not reviewed or endorsed Pleroman.
Download the machine-readable evidence record. No independent implementation, peer-review report or practical adoption study is included in this evidence release.
Reproduce before relying on the result
The kit includes the exact engine and astronomy files tested, both test suites, the evidence recorder, saved USNO responses, logs, file hashes and a review template. It needs Node.js; no package installation is required. Extract the ZIP, open its folder in a terminal and run:
node test.cjs
node test-ut1.cjs
node record-validation.cjsThe last command rechecks the stored reference responses and rewrites the evidence record locally with the new run's timestamp. It does not fetch current USNO data. The source URLs are included so reviewers can retrieve them separately. Hashes identify exact input files; they are not a certificate of correctness.
For an independent reproduction, implement the written rules without reusing the calendar engine and compare results. For an independent astronomical check, use a separate ephemeris and an explicitly documented Earth-rotation source or model.
Questions that remain open
Astronomical definition and reference method
Specify the exact equinox definition, coordinate conventions and canonical ephemeris or algorithm. Test a separately implemented calculation against the reference engine, especially when the event is near midnight.
UT1 uncertainty and revision policy
Compare the ΔT model with suitable observations and alternatives. Publish sensitivity to uncertainty near date boundaries and decide how improved predictions would affect already published future calendars.
External coverage and validity interval
Extend the three-year spot check into a documented reference comparison over an agreed interval. Distinguish observed, predicted and extrapolated dates. Internal coverage through 3000 is not external astronomical validation through 3000.
Conformance and boundary behavior
Test exact-midnight assignment, invalid inputs, time zones, negative years, all specification requirements and any discrepancies. A passing internal suite is not a completed independent audit of requirements C-01 through C-12.
Civil use and governance
Study payroll, quarters, contracts, recurring observances, accessibility and transition costs. Define who can approve revisions, issue errata and maintain authoritative tables. Consistent arithmetic alone does not answer these questions.
Make a finding reproducible
A useful review can confirm a result, identify a counterexample or challenge a design choice. State which kind of finding it is. Include the specification section, exact input date, expected and actual result, calculation method, time scale, source version and steps another person can repeat.
Download the review template. You can email your findings to Jonathan Butler or use the template in an independently published assessment. See About & contact for more about the creator of the project.
The most useful next evidence would be an implementation derived from the specification alone, a separately sourced year-boundary comparison, or a documented failure that narrows the proposal's valid scope.
Documents and sources
These are original project documents, preserved as supplied. They describe the proposal and its intentions; their statements about validation should be read alongside the dated evidence record above.
- The Pleroman Calendar — overview (PDF, 2 pages)A short introduction to the purpose and structure.
- Technical specification v0.1 (PDF, 10 pages)Working draft dated 19 September 2026. Rules, conversion algorithms, requirements and unresolved v1.0 items.
- Initial proposal for technical and scholarly review (PDF, 6 pages)Design objectives, proposed comparisons and an invitation to criticism.
- Abstract (PDF, 1 page)A compact technical summary of the proposed architecture.
External reference material
- USNO seasons service and API documentation — source of the three reference years.
- NASA: Espenak–Meeus polynomial expressions for ΔT — background for the selected model; use does not imply endorsement.
- Astronomy Engine — the astronomy dependency; its retained license is included with the code.
Read the app's detailed Methodology for its event layers, historical assumptions and export behavior.