D - Dates, Identity & Implementation

Canonical Representation, Validation and Conversion

D.1 Purpose

This appendix defines how Marian civil dates are represented, validated and converted between equivalent forms.

Its purpose is to ensure that independent implementations can identify the same civil sol in the same way even when their human-facing language, typography or local conventions differ.

The central distinction is between identity and interface.

Canonical identities belong to the calendar structure. Names and display forms sit above them. A database should not need to know whether Month 08 is displayed as Augiix, translated into another language or given a different local name altogether.

For regular Marian years MY1 onward, all date arithmetic is deterministic from the year number and the structural rules defined in Appendices A and B.

MY0 is a transitional epoch interval and is treated separately in Section D.18.

D.2 The canonical Marian Civil Date

The primary Marian Civil Date contains four components:

Year · Month · Week · Day

Its structural form is:

(Y, M, W, D)

The canonical machine-readable representation is:

MY<year>-<month>-<week>-<day>

For example:

MY42-08-03-05

means:

Marian Year 42 · Month 08 · Week 03 · Day 05

The fields have the following meanings:

Month, week and day fields use two decimal digits in canonical interchange.

The year is represented as the decimal Marian year number following the prefix MY. The specification does not require a fixed number of year digits.

Thus:

MY1-01-01-01

is the first regular Marian civil date, while:

MY142-12-08-06

identifies Month 12, Week 8, Day 6 of MY142.

Canonical strings are intended to be unambiguous identifiers. Implementations requiring lexicographic sorting SHOULD store the component fields separately or apply an agreed fixed-width year representation internally rather than assuming that variable-width display strings will sort correctly as text.

D.3 Why Year–Month–Week–Day?

The use of four components rather than the familiar Gregorian Year–Month–Day form reflects Marian's weekly architecture.

Every regular Marian month contains eight nominal week positions and begins at weekday position 1. A Marian date can therefore expose the week directly:

MY42-08-03-05

can be read as:

Year 42 → Month 08 → Week 03 → Day 05

Day 5 is not a weekday label calculated independently from a continuous seven-sol count. It is the fifth weekday position of that civil week by construction.

The same structural address therefore retains the same weekday position in every regular year in which the date exists.

This is one of the principal practical consequences of Marian's recurring-date architecture.

D.4 Human-facing forms

A canonical date may be rendered in many human-readable forms without changing its identity.

For example, the canonical date:

MY42-08-03-05

may be displayed as:

MY42 · Month 8 · Week 3 · Day 5

or, using the recommended English-language vocabulary:

Frisol, Week 3, Augiix, MY42

or:

42 Augiix · Week 3 · Frisol

These are representations of the same civil sol.

Applications MAY reorder, translate or localise human-facing components according to local conventions. They MUST preserve an unambiguous mapping to the underlying canonical date.

D.5 Canonical structural identities

The following identities are structural:

These identities remain unchanged when names are translated or replaced.

For example:

Month 08 remains Month 08.

Minth 17 remains Minth 17.

Day 05 remains weekday position 5.

This structural layer is the basis for machine interoperability.

D.6 Recommended weekday vocabulary

The canonical weekday positions are numeric. Marian recommends the following English-language display names:

These names are an interface, not the underlying identity.

A localised implementation may replace Frisol while preserving D5. Software exchanging canonical dates need not exchange the human-readable weekday name at all.

D.7 Recommended month vocabulary

The twelve canonical months are numbered 01–12.

The reference English-language vocabulary is:

The names preserve recognisable January-to-December ordering while signalling that Marian months are not terrestrial months.

They are not required for machine interoperability. A future community may translate or replace them without changing the calendar structure.

D.8 Minth identity

The canonical identities of the twenty-four minths are:

01 through 24

Their relationship to months is deterministic:

Marian also recommends the compact human shorthand:

A through X

with the direct mapping:

A = 01, B = 02, ... X = 24

Thus:

MY42 · Minth Q

means:

MY42 · Minth 17

The A–X layer is recommended shorthand rather than canonical machine identity. Other scripts or communities may use different human shorthand while retaining Minths 01–24 underneath.

Chapter 14's underlying principle is therefore preserved: canonical numbers define semantic identity; letters and names provide interfaces.

D.9 Date validity

A syntactically well-formed Marian date is not necessarily a valid Marian date.

An implementation MUST validate the actual civil position.

For MY1 onward:

• Month MUST be 01–12.
• Week MUST be 01–08.
• Day MUST be 01–07.
• The requested weekday position MUST exist within the actual length of that month in that year.

The day position within a month is:

P = 7 × (W − 1) + D

The date is valid if:

P ≤ month length

For example:

MY2-03-08-06

gives:

7 × 7 + 6 = 55

Month 3 contains 55 sols, so the date is valid.

By contrast:

MY2-03-08-07

gives:

7 × 7 + 7 = 56

Month 3 contains only 55 sols, so that date does not exist.

An invalid date MUST NOT be silently converted into the following civil date.

D.10 Month-length function

For any regular Marian year Y and month M, month length can be determined without a lookup table.

In language-neutral pseudocode:

function isLeapYear(Y):

if Y mod 100 = 0:

return false

if Y mod 2 = 1:

return true

if Y mod 10 = 0:

return true

return false

Month length is then:

function monthLength(Y, M):

if M = 3 or M = 6 or M = 9:

return 55

if M = 12 and not isLeapYear(Y):

return 55

return 56

Thus Months 3, 6 and 9 always contain 55 sols. Month 12 contains 55 in a common year and 56 in a leap year. All other months contain 56.

D.11 Date-validation algorithm

A canonical implementation may validate a date as follows:

function validDate(Y, M, W, D):

if Y < 1:

return false

if M < 1 or M > 12:

return false

if W < 1 or W > 8:

return false

if D < 1 or D > 7:

return false

position = 7 × (W - 1) + D

return position <= monthLength(Y, M)

The only possible invalid weekday position inside otherwise valid month/week ranges is therefore Week 8, Day 7 of a 55-sol month.

As shown in Appendix B, this position is always absent in Months 3, 6 and 9, and is absent in Month 12 only in a common year.

D.12 Ordinal-sol representation

Marian also supports an ordinal representation identifying a sol by its position within the year.

The canonical form is:

MY<year>-S<ordinal>

For example:

MY42-S409

means:

the 409th sol of Marian Year 42

Ordinal fields use three decimal digits for ordinary Marian years:

S001 through S668

in a common year, and:

S001 through S669

in a leap year.

The ordinal count resets at the beginning of every regular Marian year.

The civil date:

MY42-08-03-05

and the ordinal date:

MY42-S409

identify the same civil sol.

The main manuscript already establishes this dual representation and its distinction from Mars Sol Date.

D.13 Civil date to ordinal sol

Let:

P = 7 × (W − 1) + D

be the position within Month M.

The ordinal sol is:

S = sum of the lengths of Months 1 through M−1 + P

In pseudocode:

function civilToOrdinal(Y, M, W, D):

if not validDate(Y, M, W, D):

error "invalid Marian date"

S = 7 × (W - 1) + D

for m from 1 to M - 1:

S = S + monthLength(Y, m)

return S

For:

MY42-08-03-05

Month 8 begins at ordinal Sol 391.

Week 3, Day 5 is the nineteenth sol of the month:

7 × 2 + 5 = 19

so:

391 + 18 = 409

giving:

MY42-S409

D.14 Ordinal sol to civil date

Conversion in the opposite direction first identifies the month containing the ordinal sol.

function ordinalToCivil(Y, S):

maxSol = 669 if isLeapYear(Y) else 668

if S < 1 or S > maxSol:

error "invalid ordinal sol"

M = 1

remaining = S

while remaining > monthLength(Y, M):

remaining = remaining - monthLength(Y, M)

M = M + 1

W = floor((remaining - 1) / 7) + 1

D = ((remaining - 1) mod 7) + 1

return (Y, M, W, D)

Because shortened weeks occur only at the ends of 55-sol months, the procedure cannot generate a nonexistent Day 7. A remaining value in such a month never exceeds 55.

D.15 Deriving minth, quarter and Sixth

Minth, quarter and Sixth identities need not be stored independently when the Marian Civil Date is known. They can be derived deterministically.

First calculate the position within the month:

P = 7 × (W − 1) + D

The minth is then:

if P <= 28:

minth = 2 × M - 1

else:

minth = 2 × M

The quarter is:

quarter = floor((M - 1) / 3) + 1

The Sixth is:

sixth = floor((M - 1) / 2) + 1

For MY42-08-03-05, the month position is 19, so the date lies in the first minth of Month 8:

Minth 15 / O

Month 8 also lies in:

Quarter 3

and:

Sixth 4

These are additional structural views of the same date rather than independent dates.

D.16 Nominal week position within the year

Where useful, the nominal week position within a Marian year can also be derived:

annual week position = 8 × (M − 1) + W

This produces values from:

1 through 96

Every regular Marian year contains all 96 nominal week positions.

The term nominal is important. A terminal week in a shortened month contains only six occupied weekday positions, so 96 nominal weeks do not imply 672 physical sols.

Applications SHOULD therefore avoid treating the annual week position as a continuous count of seven-sol intervals.

D.17 Counting leap years before a given year

Deterministic long-range conversion requires knowing how many leap sols have occurred before a particular Marian year.

For years MY1 onward, the number of leap years from MY1 through MYN inclusive is:

L(N) = floor((N + 1) / 2) + floor(N / 10) − floor(N / 100)

The three terms count:

• odd-numbered years;
• additional years divisible by 10; and
• century years removed by the exception.

For example:

L(100) = 50 + 10 − 1 = 59

For conversion purposes, the number of leap years preceding MY Y is therefore:

Lbefore(Y) = floor(Y / 2) + floor((Y − 1) / 10) − floor((Y − 1) / 100)

Thus the number of complete sols between the start of MY1 and the start of MY Y is:

Δ(Y) = 668 × (Y − 1) + Lbefore(Y)

This provides the basis for deterministic conversion across Marian years without iterating through every preceding year.

D.18 Marian epoch-sol offset

For implementation, it is useful to define an internal zero-based sol offset from the beginning of MY1.

Let:

E = the canonical Airy-0 midnight beginning MY1

and let:

S be the ordinal sol within year Y.

Then the zero-based number of completed Marian sols from E to the beginning of that civil sol is:

Δsol = 668 × (Y − 1) + Lbefore(Y) + (S − 1)

This quantity is an implementation intermediate, not a new public calendar notation.

For example, the first sol of MY1 has:

Δsol = 0

The second has:

Δsol = 1

and the first sol of MY2 follows the 669 sols of leap MY1.

Once the historical MY1 epoch has actually occurred and its absolute timestamp has been authoritatively recorded, this offset provides the discrete civil bridge between Marian chronology and external time systems.

D.19 Converting a sol offset back to Marian date

Given a non-negative number of completed sols Δsol since the beginning of MY1, an implementation must first identify the Marian year containing that sol.

A convenient initial estimate is:

Y = floor(Δsol / 668.59) + 1

Because this is only an estimate, the implementation then adjusts against exact civil year boundaries:

while startOffset(Y) > Δsol:

Y = Y - 1

while startOffset(Y + 1) <= Δsol:

Y = Y + 1

where:

startOffset(Y) =

668 × (Y - 1)

+ leapYearsBefore(Y)

The ordinal sol is then:

S = Δsol - startOffset(Y) + 1

and Section D.14 converts that ordinal sol into Month–Week–Day form.

The approximate divisor is therefore only a search shortcut. The final result MUST be determined using the integer calendar rules.

D.20 MY0

MY0 does not use the ordinary regular-year conversion formulas.

It begins at the recognised first human step on Mars and ends at the Airy-0 midnight that begins MY1 following the next passage through Ls = 15°.

Its length will depend upon when the historical landing event occurs within the Martian annual cycle.

MY0 is therefore a transitional epoch interval, not a 668- or 669-sol regular year.

Until the historical event occurs, no definitive mapping can exist between an MY0 position and an absolute timestamp.

A future implementation standard will need to define how civil dates, mission-relative sols or other records are represented during MY0. That decision SHOULD preserve the recognised first-step epoch without pretending that the partial interval possesses the normal twelve-month structure before that structure actually begins.

Regular Marian date algorithms in this appendix therefore apply from MY1 onward.

D.21 Marian ordinal sol is not Mars Sol Date

The Marian ordinal representation:

MY42-S409

must not be confused with Mars Sol Date (MSD).

They solve different problems.

The Marian ordinal number resets at every Marian New Year.

MSD does not.

An implementation MUST NOT label a Marian ordinal-sol value as MSD.

Where scientific and civil coordinates are both required, they should be carried as separate fields.

D.22 Conversion to external calendars and timestamps

Marian chronology is fully deterministic internally from MY1 onward, but absolute conversion to Gregorian dates, UTC, TAI, MSD or another external chronology requires an externally defined bridge.

That bridge cannot be completed before the Marian epoch exists.

A future authoritative implementation will require, at minimum:

1. the agreed physical timestamp of the recognised first human step;
2. the resulting determination of the first subsequent Ls = 15° passage;
3. the canonical Airy-0 midnight beginning MY1; and
4. an agreed astronomical/timekeeping model for relating Martian mean solar boundaries to the external timescale being used.

Once the MY1 epoch is fixed, conversion can proceed conceptually as:

Marian Civil Date → Marian ordinal sol → sol offset from MY1 → absolute chronology → target civil calendar

and in reverse:

absolute chronology → sol offset from MY1 → Marian year and ordinal sol → Marian Civil Date

The integer Marian portion of that conversion is fully specified here.

The astronomical bridge between an Airy-0 sol boundary and terrestrial continuous timescales belongs to the implementation standard and Earth–Mars conversion work described in Appendix E.

D.23 Do not convert using an approximate sol length

A Martian mean solar day is commonly described as approximately 24 hours, 39 minutes and 35 seconds of terrestrial elapsed time.

That approximation is useful for human intuition. It is not, by itself, a sufficient high-precision conversion standard.

Software SHOULD NOT convert long spans between Marian dates and terrestrial timestamps merely by multiplying the number of sols by a rounded value such as 24:39:35.

Authoritative conversion should use the agreed Martian time model and epoch definition appropriate to the required precision.

For ordinary calendar arithmetic within Marian itself, none of this is necessary. Integer sol counts are sufficient.

D.24 Recurring dates and absent positions

Marian contains several structurally absent civil positions.

For example:

Month 03 · Week 08 · Day 07

does not exist.

A recurrence rule requesting such a position therefore requires an explicit application-level policy.

Possible policies might include skipping the occurrence, moving it to the preceding valid position or moving it to the next civil date. Marian itself does not choose among those behaviours.

The calendar specification defines only that the requested date is invalid.

A conforming core implementation MUST NOT silently reinterpret an invalid Marian date as another valid date. Any adjustment policy belongs to the scheduling, legal or institutional application using the calendar and should be made explicit.

This distinction prevents different software systems from quietly giving different meanings to the same nominal recurrence.

D.25 Date arithmetic

Date arithmetic should distinguish between civil coordinates and elapsed duration.

Adding one sol to a valid Marian date means advancing to the next physical civil sol, including across shortened terminal weeks.

For example, in a 55-sol month:

M3 · W8 · D6

plus one sol becomes:

M4 · W1 · D1

It does not become the nonexistent:

M3 · W8 · D7

Similarly, adding a fixed number of sols is not always the same operation as adding one minth, month, Sixth, quarter or year.

Applications SHOULD therefore specify the intended arithmetic operation explicitly.

“Add 28 sols” is an elapsed-duration operation.

“Advance to the same position next minth” is a civil recurrence operation and may require validity handling.

This distinction is familiar in terrestrial date software and becomes particularly important in a calendar with deliberately shortened terminal civil weeks.

D.26 Comparison and ordering

Two Marian Civil Dates can be chronologically compared by converting each to:

year-start offset + ordinal sol

For dates within the same year, ordinal sol is sufficient.

For dates across regular years:

absolute Marian sol index = Δ(Y) + S − 1

where Δ(Y) is defined in Section D.17.

The earlier date has the smaller index.

This comparison does not require astronomical computation once MY1 exists.

D.27 Storage recommendations

A robust implementation should distinguish between canonical semantic fields and display strings.

A database record might store:

Human-facing software may then render:

Frisol, Week 3, Augiix, MY42

without making Frisol or Augiix database keys.

Derived fields need not be permanently stored if they can be calculated reliably from the canonical tuple.

Where both a Marian date and a precise event time are required, applications SHOULD store the civil date alongside the relevant local-time convention and an appropriate absolute timestamp rather than attempting to encode all temporal information inside the Marian date string.

D.28 Parsing rules

A parser for canonical Marian Civil Dates SHOULD:

1. require the MY prefix;
2. parse the following positive decimal integer as the Marian year;
3. require three hyphen-separated two-digit structural fields;
4. interpret those fields as Month, Week and Day;
5. validate each numeric range;
6. calculate the applicable month length from the year and month;
7. reject any civil position beyond that length.

Thus:

MY42-08-03-05

is valid.

MY42-13-03-05

is invalid because Month 13 does not exist.

MY42-08-09-05

is invalid because Week 09 does not exist.

MY42-09-08-07

is invalid because Month 09 contains only 55 sols.

Parsers SHOULD distinguish malformed syntax from a structurally well-formed but nonexistent date where their error model permits it.

D.29 Formatting rules

Canonical interchange uses:

MY42-08-03-05

rather than:

MY42-8-3-5

The leading zeros make the three structural subdivisions visually stable and remove avoidable formatting variation.

Human-facing interfaces MAY omit them:

MY42 · Month 8 · Week 3 · Day 5

Natural-language interfaces MAY omit redundant structural information where context makes the date clear.

No human display convention changes the underlying canonical tuple.

D.30 Identity survives localisation

The reference vocabulary is intentionally replaceable.

An English-language settlement may display Augiix. Another community may translate it. A third may replace the month names entirely. All three still share the same civil date if they exchange:

MY42-08-03-05

The same applies to weekday and minth names.

This is why Marian standardises the structure more strongly than its vocabulary. As Chapter 14 puts it, the aim is for the calendar to survive translation and cultural change while retaining stable machine identity.

D.31 What a Marian Civil Date does not encode

A Marian Civil Date identifies a civil sol.

It does not by itself encode:

• time within that sol;
• a local Martian time zone;
• longitude;
• Ls;
• Mars Sol Date;
• a terrestrial timestamp;
• Earth–Mars light time; or
• the physical position of either planet.

Those quantities may be associated with the same event, but they are separate coordinates.

A scientific observation may therefore carry a Marian Civil Date, local or canonical Martian time, an absolute timestamp, MSD and ephemeris information simultaneously.

That is not duplication. Each field answers a different question.

D.32 Minimum implementation test set

A useful reference implementation should at least verify the following cases:

A complete conformance suite should extend this set across century boundaries, all shortened months and both year templates.

D.33 Implementation summary

For regular years MY1 onward, Marian requires only a small set of deterministic operations:

The calendar does not require an ephemeris to perform ordinary civil arithmetic.

Once MY1 is established, the structural calendar can be implemented using integer arithmetic alone.

That is the intended result of separating scientific time, civil chronology and human-facing vocabulary. The underlying machinery remains stable; interfaces can evolve around it.

A Marian date should survive a change of language, software or settlement without ceasing to identify the same sol.