The Smoital System — A method of timekeeping on Mars based on UTC

Abstract

Designing a timekeeping system for Mars requires balancing multiple priorities: familiarity with Earth conventions, avoidance of unit confusion, interoperability with Earth time, compatibility with existing software and infrastructure. Many existing Martian timekeeping proposals might be suitable for long-term use on Mars, however the initial years of a Martian colony might benefit from a UTC-based system for simpler initial setup.

This paper introduces Smoital (Synodic Mars-Orbit Intercalary Timezone Alignment), a timekeeping system which is suitable for initial civil use on Mars, closely tracking mean solar time, but optimised for ease of integration with existing software by relying on standards ISO8601 [1], and the IANA Time Zone Database [2]. The system specifies nearly all Martian calendar days as exactly 24 hours and 40 minutes in length (Earth units), closely matching the true Martian solar day, with the exception of 6 or 7 intercalary days per Martian year, which are defined as only 24 hours long. The shortened days compensate for the excess duration accumulated over the year, without requiring redefinition of hours, minutes, or seconds.

By strategically distributing the shortened days throughout the Martian year, Smoital allows for built-in correction of Mars’ highly variable equation of time, as well as optional native support for daylight saving time, without having to introduce new mechanisms or new timezone offsets. The shortened days are always designated as the 37^th day (at timezone offset UTC−12:00) following a 36-day sequence (timezone offsets UTC+12:00 to UTC−11:20), allowing for a compact and easy-to-interpret chart of calendar timezone offsets, enabling simple human memorisation or lookup of all UTC offsets for an entire Martian year.

Implementation ideas are presented, demonstrating how this system can be immediately activated on current operating systems, followed by proposed standards extensions which will allow a transition into a more Mars-centric time representation. Such proposed standards extensions would be both backwards compatible with Smoital (and UTC), as well as forwards compatible with other Martian time-keeping systems; thus, Smoital can be viewed as a practical “bridge”, suitable for the first few years or decades of a Mars colony.

SmoitalSynodic Mars-Orbit Intercalary Timezone Alignment

Conventions of this paper

• Time units of hours, minutes, seconds, milliseconds are defined as Earth time units, unless otherwise specified.
• A day refers to a Martian sol unless otherwise specified.
• A Martian Sol is taken as exactly 24 hr 39 min 35 sec 244 ms [3]
• A Martian Year is taken as approximately 668.6 Martian Sols (precise calendars are not a focus of this paper)
• The term “synodic” is used loosely throughout, to usually refer to synchronisation of the Mars-Sun direction and the Earth-Sun direction.
• The Martian year in charts is measured from perihelion (different to many other papers)
• A period of 36–37 days taken for the time on Mars to realign with Earth is referred to as a ‘Smonth’.
• Any day that is made to be shorter than a standard day on Mars is referred to as a ‘Smol’.
• Under any Martian clock system based on UTC, the next date after a Smonth would involve a UTC offset increase of 24 hours. Such a jump will be referred to as a ‘skipped date’.

1. Most Common Existing Solutions

Many proposals have been made for Martian time-keeping systems; however many of them would be difficult to implement outside of a controlled environment. Once humans are on Mars, they will bring with them all sorts of computing devices such as servers, laptops, tablets, and smartphones. Such devices will be running and interacting with legacy programs written in millions of lines of code that have mostly all been designed around UTC and Earth time units as the primary timekeeping system.

If a Martian colony were to immediately start using a unique, specially designed timekeeping system for Mars, then integration with Earth time will become an extremely large technical challenge, potentially forcing Martian colonists to use two parallel time-keeping systems that are very difficult to compare and organise in software and in databases.

The split in incompatible time-keeping systems could pose not only a challenge to Martian colonists, but also present a roadblock to Earth-based software developers, delaying the implementation of Mars time support in general software, causing unit conversion complexity for Martian colonists, as well as possibly limiting cross-planet communication.

We will begin by comparing four well-known ideas on how to use time on Mars, each of which must contend with the Martian day being 2.749125% longer than on Earth.

B) Mars Stretched Time

In the long term, adopting a Martian sol-based time system is a reasonable and desirable goal. A fully self-sufficient Martian colony, operating within its own light-time bubble and its own relativistic time dilation gravity-well, would benefit from a native time standard tailored to local conditions. However, during the early years or decades of colonisation, reliance on Earth will remain high. In this phase, priorities such as safety, operational stability, and seamless interoperability with Earth-based systems are likely to outweigh any symbolic or practical push for Martian timekeeping independence.

The failure of the Mars Climate Orbiter in 1999 [6], a spacecraft that crashed into the surface of Mars due to a mix-up of imperial and metric units, resulting in a loss of over $300 million, is a good example of why using multiple different unit systems is a risky decision. Given that Mars time units under this system very closely resemble Earth time units, it’s easy to imagine critical errors arising, potentially even more frequently than the infamous confusion between feet and meters.

Technically, stretched time units could be adapted to work with UTC offsets. However, because of the redefined units, the UTC offset would continuously shift by approximately 27 milliseconds per second, making integration with Earth time considerably less elegant.

If this unit of time were adopted on Mars, then converting timestamps between Earth and Mars would become cumbersome. One could imagine that if this system were implemented on Mars, there would be a designated “epoch” at which a specific Earth and Mars timestamp are considered exactly equal, and time would diverge from that moment onward. One Mars second after that epoch would be 1.02749125 Earth seconds later, meaning that direct comparisons between Mars and Earth time would require nanosecond precision. Conversely, one Earth second from the epoch would be 0.973244297700832... Mars seconds (a decimal that eventually repeats after 821,992 digits).

As a result, timestamps in databases would likely be handled in one of several ways: primarily stored in Earth units and displayed as Martian time on demand, rounded continuously during conversions, recorded with sufficient precision for both units, or retained with extra data fields indicating the unit. Comparisons between timestamps would require very high-precision to avoid edge cases where values appear equal despite differing by tiny fractions of a second.

2. Equation of Time (Mean Solar Time)

To demonstrate just how extreme the effect of Mars’ orbit is, the “Equation of Time” chart below displays a full year on both Earth (blue) and Mars (red), beginning at Perihelion for both (closest approach to the Sun).

• Hour/minute/seconds are in Earth units.
• The times being charted are those resulting from use of a mean solar clock (not Smoital time).
• The vertical position of each curve indicates the time that solar noon occurs for that day of the year.

Mars has a much longer curve as there are about 668.6 days in a Mars year [9], compared to around 365.25 on Earth.

• The range of times for solar noon on Mars is over 93 minutes, compared to a range of less than 31 minutes on Earth.

The chart to the right is the same information displayed as a distribution bar chart.

• Each horizontal 1px-high bar represents a 1 minute “bucket”
• The horizontal width of the bar is proportional to how frequently solar noon lands in that minute
• The total area of each shape is made to be equal
• The distribution chart is aligned horizontally to match the vertical axis of the main plot

The flow-on effect of a highly variable equation of time is that sunrise and sunset will have additional variation beyond that caused solely by the seasons (axial tilt). The variation is so extreme on Mars that some may call on implementing DST even at the equator.

3. Key Smoital Features

Given the advantages and disadvantages outlined previously, the Smoital System, which is intended for immediate use on Mars, builds upon the Mars “Extended Time” system, but takes advantage of the following coincidence:

William Lloyd Napoli published a paper called Interplanetary Calendars in 2004 at the Mars Society [10], in which a proposal was made to increase most Martian days to 25hr, with some days being 24 hr. Such a system bears many similarities to the Smoital system, however it was designed primarily for flexibility throughout the solar system, rather than directly taking advantage of this coincidence.

The Smoital system defines nearly all days as exactly 24 hr 40 min (referred to as Standard Days), with the exception of 1.0315% of days defined as 24 hr (referred to as Smol Days). This choice results in a minimum of 36 unique timezones rather than 24 timezones used by Napoli. The most immediately clear advantage of this choice is that very few days are varied from the Standard 24 hr 40 min, whereas Napoli’s system has roughly 34% / 66% split between 24 hr and 25 hr days.

The constant of 1.0315% for the proportion of Smol days appears like a rounded figure; however it is an exact result based on the below equalities:

• Martian day length = 24 hr 39 min 35 sec 244 ms — expressed in hours:
• = 24 + 39 / 60 + 35 / (60 × 60) + 244 / (60 × 60 × 1000)
• = 24.65979
• = 24 + 39.5874 / 60
• = 24 + (40 × 0.989685) / 60
• = (24 hr + 40 min) × 98.9685% + (24 hr) × 1.0315%

To determine the number of Smol Days per year, we calculate the following (based on approximately 668.6 Sols per Martian year):

668.6 × 1.0315% = 6.896609 ≈ 6 × 10% + 7 × 90% (approx.)
(i.e. ~10% of years have 6 Smol days and ~90% have 7)

If, in the future, the length of the day of Mars is observed to greater precision then these constants may require adjustment; however, the principles of the Smoital system can work within a large range of deviation, well into the future.

The Smoital system also includes the following design choices, which will be justified later in this article:

• The Smol days in the Smoital system will be chosen to always occur at a consistent additional timezone offset of UTC−12:00, separated by some multiple of 36 days. This extends the number of unique timezones in the system from 36 to 37, but comes with significant advantages.
• Given that not all Smonths are 37 days long, the distribution of 36 vs 37 day Smonths is a key consideration. The standard, and seemingly best-fit distribution, appears to be:
  1. ...
  2. 36
  3. 36
  4. 36
  5. 37
  6. 37
  7. 36
  8. 37
  9. 37
  10. 36
  11. 37
  12. 36
  13. 37
  14. 36
  15. 37*
  16. 36
  17. 36
  18. ...

  *the final 37 is omitted in approx. 10% of years.

Although Smoital manipulates the length of days on Mars, it will be demonstrated in this article that by doing so, the irregularities resulting from this manipulation will cancel out against the irregularities already existing on Mars due to the highly eccentric orbit, and in fact make for a more stable time-keeping system overall. The resulting time of midday will be more narrowly constrained (see Section 5), and for extreme latitudes the irregular time of sunrise can be made more constrained (see Section 7).

The following page shows how an entire year of Martian days would thus end up, aligned in such a system. This type of chart is referred to in this paper as a ‘Smoitus’.

Note:

• Each row is referred to as a ‘Smonth’.
• The Day-of-the-Smonth (‘D’) is numbered 1–37 in the top row.
• The timezone of each column is shown at the bottom of the Smoitus.
• The days progress right-to-left, to allow the map of Earth to be displayed below, generally corresponding with the timezone offsets.
• This chart does not demonstrate a calendar proposal. Any other calendar system of months or weeks can be integrated / overlaid on a Smoitus.

There are many advantages to placing the Smol dates consistently as the 37^th day of the Smonth at UTC−12:00:

• The day-of-the-Smonth (‘D’) not only uniquely describes the Timezone offset, it is also the only information required to determine whether a given day is Standard or Smol.
• Since the days of the Smonth can be numbered clearly, a conversion from Earth and Mars dates can be easily used. For example, if the Earth date which was “Skipped” at the start of the Smonth is known, then the current Earth date for any day-of-the-Smonth (‘D’) is equal to ‘Skipped Date’ + ‘D’. The skipped date can then be shown as its own column on the right of the Smoitus, facilitating Earth /Mars date conversion.
• Visualisation of the Smoitus is compact, allowing each Smonth to occupy only one row.
• The number of days in a Smonth is established as varying between 36 and 37, the number of unique timezones matches this natural fact.
• The software implementation of the timezone offset schedule is simplified (the implementation will be described later in this article).

Using this system, the timezone for any given date can be determined (by a human) in one of three ways:

• Checking vertically to the axis at the bottom of the Smoitus; or-
• Memorising the day-of-the-Smonth (‘D’) to Timezone mapping - e.g. day 1 is always UTC+12:00, day 19 is always UTC+00:00 etc.
• Using the formula: $$\underset{(minutes)}{\text{UTC-Offset}}=760-40D$$

The choice of using 37 timezone offsets may seem unintuitive at first, re-using one of the other 36 offsets being an obvious alternative choice. The reasons are as follows:

• If UTC+12:00 is used early (and thus twice) instead of UTC−12:00, then the 24 hr jump forward would occur between the 36^th and 37^th days, instead of at the consistent position prior to the first day of the Smonth.
  This would break the formula: $$\text{Earth-Date}=S+D$$
• If UTC−11:20 was repeated, then the Smol date would occur on the 36^th day.
  This would break the formula: $$\text{Day-Length}=\{\begin{array}{ll}\text{24:40:00}& D\in [1,36]\\ \text{24:00:00}& D=37\end{array}$$
• Either option would break the formula: $$\underset{(minutes)}{\text{UTC-Offset}}=760-40D$$

How Timezone Conversion is Used
In practice, the “current” time on the other planet would usually need to be combined with the current light-time delay between Earth and Mars, which changes very gradually. These two pieces of information allow one to determine the times of interest, either mentally or electronically.

The figure below shows an example of how a dashboard might appear on Mars, when the local timezone is UTC+2:40, and light delay is 10 min 16 sec.

4. Aligning the Day Around 12:00 as Mean Solar Noon

Some other advantages to anchoring 12:00 at mean solar noon include:

• Waking hours would feel like Earth time, as sunrise, noon and midday all occur around times that one would normally expect, and people would usually not be awake during the sole part of the day that significantly differs.
• The “messy” additional time has now been inserted equally at the start and end of the solar cycle, representing an additional form of symmetry.
• The periods of “AM” and “PM” are now reasonable concepts (ante meridiem and post meridiem literally mean before/after midday).

5. Equation of Time (Smoital System)

The effort to use the Smoital system would probably not be worth it if the system did not at least maintain a reasonable equation of time. Fortunately, it not only maintains a reasonable equation of time, but it significantly improves upon the default one:

It is surprising that even with so many restrictions on the dates that can be Smol, we are able to achieve a fairly well-constrained equation of time. Although the range of possible offsets is only slightly constrained, the overall distribution is much more compact.

• A random day on Mars using a mean solar clock can expect solar noon on average to be nearly 28 minutes away from 12:00.
• A random day on Mars using the Smoital system, can expect solar noon on average to be under 12 minutes away from 12:00.

6. Distribution of Smol Dates

Although the Smol dates are constrained to the 37^th Day-of-the-Smonth, there is freedom to decide which Smonth (row) to place them in.

7. Daylight Savings Time

The idea of “Daylight Savings Time” is fairly controversial, and whether somebody likes or dislikes it seems to usually depend on whether the person is a morning or evening person. As of 2025, the majority of Earth’s economic output occurs within regions that use daylight savings time, and the idea cannot be discarded purely on the optimistic idea that future colonists would be rational beings above the “primitive” practice of annual clock adjustments.

Although some of the features of this timezone schedule seem unusual, they each have precedent within the IANA Timezone database. The following section will compare each of these unusual features with their Earth based precedents.

• Partial hour offsets are very common on Earth, in fact over 20% of the global population lives in Timezones using a partial hour offset from UTC [12]. Some prominent examples include:

  • South Australia: UTC+9:30
  • Canada — Newfoundland: UTC−3:30
  • New Zealand — Chatham Islands: UTC+12:45
  • French Polynesia — Marquesas Islands: UTC−9:30

  • Iran: UTC+3:30
  • India: UTC+5:30
  • Nepal: UTC+5:45
  • Myanmar: UTC+6:30

• Implementing a 24 hour timezone change to swap over the international date time has been implemented in a handful of countries. Most recently Samoa skipped 2011-12-30 and Kiribati skipped 1994-12-31 [13]. Standard calendar programs such as Apple Calendar and Google Calendar support these skipped dates, by removing the date from the UI, or disallowing events to be added to the skipped date. Although these are historical cases only, software providers would be well advised to support skipped dates in this manner going forward, as other regions such as the Cook Islands and Niue have a reasonable chance of making the same decision in the coming years or decades, possibly with little warning.
   
• The practice of setting a clock back at midnight, which extends the length of a day with extra minutes appended precisely at the end (rather than around 2 am or 3 am), is standard annual practice in Nuuk, Greenland (as of 2025) [14] . This region ends daylight savings time at midnight, repeating the period 23:00 to 23:59. This reason this is done at this time in that region is that the DST shift coincides with similar DST shifts in Europe around 2 am or 3 am etc. avoiding any period (however brief) where the relative timezone offset is not constant.
   

• Timezone adjustments for DST in most countries occur many months apart, whereas Smoital has timezone adjustments nearly every day. While there is no precedent for this extreme frequency of adjustment, there are many regions with multiple timezone changes in rapid succession throughout recent history. Some short-lived timezone adjustments in the IANA database are shown in the table below. In each case the reason for the rapid succession of clock changes is due to a late cancellation of DST for various reasons.

  Region	Start	End	Duration
  Cambridge Bay (Canada)	29 Oct 2000	5 Nov 2000	7 days
  Boa Vista / Recife / Noronha (Brazil)	8 Oct 2000	15 Oct 2000	7 days
  Asunción (Paraguay)	6 Oct 2024	15 Oct 2024	8 days
  Tucumán (Argentina)	1 June 2004	13 June 2004	12 days
  Fortaleza, Maceió (Brazil)	8 Oct 2000	22 Oct 2000	14 Days

  Whilst Smoital changes clocks more frequently (nearly every day), each timezone adjustment is confined to just one calendar date, and is therefore conceptually not too different, and as long as a software program is not incorrectly hard-coded to expect at most one timezone change per month (which would cause bugs for these Earth timezones), it should automatically adapt to support Smoital.

• Clock adjustments measured in minutes rather than hours, as well as non-standard day lengths have been experienced many times in many countries on Earth. The table below shows all unique day lengths found in the IANA timezone database between 1970-01-01 and 2024‑12‑31 (excluding Antarctica). Note: only one example at most is selected per-day-length, however many other instances have occurred.

10. Example Code Implementation of the Extra 40 min

If a system Timezone library has been updated to support a Smoital timezone schedule, then the system would not need to pass any special flags a frontend user interface in order to implement alias time display correctly for Mars. The frontend can just check if the time is 23:20 or later, and if 40 minutes ago the timezone was 40 minutes different, then the alias logic can activate. There is no other timezone on Earth that ever made a 40 minute backwards UTC timezone change later than 23:00, and so when such a change is detected, the alias can safely activate; although to future-proof against potential Earth timezones that may make a similar adjustment one day, further date checks or a timezone name lookup might be suitable.

The below example code, written in JavaScript, demonstrates functions to display the correct time for both Earth, as well as Smoital timezones, in all cases.

// Note: calls to date.getTimezoneOffset() in JavaScript return negative
// numbers in the East, which is the opposite to most other standards.
// This helper function returns it in the correct sign.
const getTrueUtcOffset = date =>
    -date.getTimezoneOffset(); // already in minutes

const getAliasUtcAdjustmentMinutes = (date) => {
  if (date.getHours() === 23 && date.getMinutes() >= 20) {
    const fortyMinAgo = new Date(date.getTime() - 2400000); // 40*60*1000
    const delta = getTrueUtcOffset(fortyMinAgo) - getTrueUtcOffset(date);
    if (delta === 40) {
      return delta;
    }
  }
  return 0;
}

const getAliasUtcOffset = (date) =>
  getTrueUtcOffset(date) + getAliasUtcAdjustmentMinutes(date);

// isExtendedMode allows for 23:99 time, otherwise 24:39 time
const getAliasMinutes = (date, isExtendedMode) => {
  const min = date.getMinutes() + getAliasUtcAdjustmentMinutes(date);
  return isExtendedMode ? min : min % 60;
}

// isExtendedMode allows for 23:99 time, otherwise 24:39 time
const getAliasHours = (date, isExtendedMode) => {
  const hr = date.getHours();
  return (hr < 23 || isExtendedMode || getAliasMinutes(date, true) < 60)
    ? hr
    : hr + 1
}

11. Mapping of Gregorian Dates to a Martian Calendar

Once Smoital time is implemented (or any Martian timekeeping system based on UTC) there exists not only a time on Mars expressed in terms of UTC, but also a natural local Gregorian date. Upon immediate arrival on Mars, it might be most practical to continue using the Gregorian calendar, however after some time one would expect a Martian calendar, for example Darian or Zubrin’s calendar to be adopted.

Mapping a Gregorian date to a Martian calendar date is fairly straightforward, not much more complex than, for example, mapping a Gregorian date to a date in the Julian, Chinese, Jewish, or Tabular Islamic calendars. The main difference in this scenario is that a skipped date will either map to: no date; the infinitesimal moment between two other dates; or overlap the next date. The appropriate choice may depend on the context.

If multiple colonies exist on Mars, it would be preferable that they maintain a constant relative UTC offset between each other. For example, a colony 90 degrees East of another might prefer to wrap their timezone offsets between UTC−6 and UTC+18, rather than between UTC−12 and UTC+12. By doing so, there will be no disagreement as to which Gregorian date the local Martian calendar date relates to, allowing the conversion between Earth-Mars date systems to not depend on local timezones.

12. Future Implementation — Standards Extensions

While the implementation discussed in Section 8 can be rolled out immediately, it is not the most optimal way to specify the timezone schedule in the medium to long term. The system itself is quite verbose in its timezone rule set, and the optimised clocks require development ad-hoc. A computer program that is made for use on both Earth and Mars, would need to manually decide whether to display the final minutes of the day as 24:00 to 24:39 based on a lookup table of timezone names, or automatically based on the fact of the adjustment being specifically 40 minutes at the end of the day (which could in rare cases cause incorrect output should an Earth timezone ever decide for whatever reason to adjust by 40 minutes in that manner).

2. Standards Extension: Modulo repeating IANA Timezone rules:

• Allow adjustments to be specified relatively, rather than absolutely against the zone’s default
• Allow a rule to be specified to recur daily, with modulo arithmetic

3. Standards Extension: Sub-second UTC offsets

Currently, the IANA timezone database supports timezone offsets specified in seconds. In practice, these are only defined for timezone regions for periods prior to modern times, and as such, many software libraries only support whole-minute UTC offsets. To pave the way for true Martian timekeeping as outlined in the next section, a standard extension that allowed millisecond, or sub-millisecond, UTC offsets, would be required.

Finally, if multiple colonies exist on Mars, they may desire a constant relative UTC offset between each other. At a minimum, UTC offsets of ±24 hours would be required to support all potential timezone offsets across Mars, however in practice it might be better for systems to support a greater range, say up to ±32 hours for future-proofing. While the IANA timezone database does not specify a maximum UTC offset, software libraries which currently restrict the offset to ±14 hours may need amendment.

13. Future Implementation — Mars Native Time

A longer-term standard would be expected to be required to allow for a true Martian native time, with either extended time (39 min 35 sec 244 ms) or with stretched time units. This topic has been covered by other writers, creating a Martian version of UTC called MTC. As suggested previously, this would be the most difficult to roll out, so it could be designed and developed in parallel to the Smoital system being in effect, initially for scientific use, and eventually for general civil use.

Whole-millisecond rounding

A clean solution would be to adopt the simple definition used in this paper: that one Martian second is defined as exactly 24 hr 39 min 35 sec 244 ms (or 1.02749125 seconds) — Earth units. Clocks on Mars would still need to run slightly slower to account for relativistic effects; however, this adjustment would apply equally to both Martian and Earth units, keeping them in sync. This adjustment would only be necessary for high-precision scientific work—not civil clocks

The next table shows the converted time units for various time increments using this constant:

Whole-second rounding

An alternative choice would be to round the length of the day on Mars to a second. Rather than round down, rounding up to 24 hr 39 min 36 sec would be a useful choice, as it results in a conversion ratio from Earth to Mars units of exactly 2.75% — equivalent to 411:400. This conversion ratio is discussed by Zubrin in The Case for Mars [5], although the text does not specify whether the figure is rounded for illustrative purposes or intended for practical use.

Such a conversion ratio allows most standard units to be expressed completely accurately in both base 10 and base 60 with minimal decimal places:

This decision, to accept a rounded unit definition has precedence on Earth:

• In 1959 the imperial inch was defined as exactly 25.4 millimetres.
• The Chinese calendar, Persian calendar, and various forms of the Lunar Hijri calendar are calculated using formulas of round-number hours offset from UTC, effectively causing these symbols of national pride to depend on the rounded relative longitude offset from Greenwich, rather than the actual physical location of their nation’s capitals. This is used not just for their timezone, but the calculation of month lengths within those calendar systems.
• A4 paper size is defined as exactly 210 mm × 297 mm, even though the precise geometric aspect ratio it is based on involves irrational numbers.

We will let:

• $${\text{SmoitalTZ}}_{y,d}=$$ the timezone offset for a given day (d) — zero indexed, for a given year (y).
• $${\text{NaturalTZ}}_{y,d}=$$ a likewise timezone offset in an ‘Additional Time’ system which seeks to obtain mean solar noon at exactly 12:00.
• $$\text{round40min}(tz)=$$ a function that rounds a timezone offset tz to the nearest 40 min offset (preferring to round up when equal distant).
• $$\text{wrap24hr}(tz)=$$ a function that modulates a timezone tz within the range UTC−12:00 (exclusive) to UTC+12:00 (inclusive).

The number of Smol days in a year is then given by:

15. Designing a Calendar Around the Smoital System

The natural 36/37-day Smonth initially appears like a suitable mechanism to build a calendar system around. This has been left outside the scope of this paper due to the following disadvantages:

• The year contains a non-integer number of Smonths, which will naturally require leap-smonths, and all the disadvantages associated with a lunar-solar calendar (year length fluctuates significantly).
• The Smonth is largely an Earth-focused concept, minimising the significance of Mars’ characteristics as the basis for the calendar.
• Unlike lunar cycles, there is no natural origin for the beginning of the Smonth, other than the human construct of Greenwich as the prime meridian.
• The beginning of the Smonth also depends on the Martian longitude of the settlement upon which it is optimised, making the calendar highly localised and not clearly universally applicable across Mars.
• Settlements at different latitudes might want to use different Smoital schedules, and a decision that affects time of day should usually not affect calendar design choice.

Nevertheless, the one aspect of the Smoital system that might seem appropriate for affecting calendar design might be the choice of the start of the year. A Smoital system is easiest to implement, and a Smoital chart easiest to read, if the year begins near Perihelion or the Southern Solstice, as this is the period where the day length is longer than 24 hr 40 min, and all Smol schedules for all latitudes are distributed over periods that would not straddle the end of the year.

Other advantages of beginning the year in this period include:

• The apparent size of the Sun, and global atmospheric pressure are both at significant maximums near this period, representing a global phenomenon unique to Mars, free of hemispheric bias
• The year and seasons will be very familiar and interchangeable for anyone already familiar with the Gregorian calendar, which also begins between perihelion and the Southern Solstice

Whilst perihelion as an anchor point for the year is not a natural choice for either calendar designers or astronomers, anchoring the Northward Equinox at 1/4 point of the year would achieve the same results, whilst keeping the calendar anchored and easily interchangeable with astronomical data, which is usually measured from the Northward equinox. My simulation appears to indicate that several thousand years would need to pass before the Milankovitch cycles cause such an anchoring to have Smonths overlapping the end of the year.

16. Comparison to Napoli’s system

If we want a day-length and a UTC offset which are both defined in whole-minutes, a necessary consequence is that not all days will be equal in length. Napoli's proposal [10], to increase most days to 25 hr, with some days being 24 hr, did not go into much detail as to the precise schedule of timezone adjustments, however on the assumption that the 25 hr days are distributed evenly throughout the year, we can see how this system will work by charting the daily offset from a true (mean solar) clock:

By comparison, in the Smoital system, if the Smol Days are distributed evenly, the deviation from mean solar time will be at a maximum of ±20 min, and the deviation chart as per below:

17. Alternative Smoital Schedules

We have presented two Smol schedules previously, being the “Standard” schedule as well as those optimised for natural daylight savings schedules at deeper latitudes, however it is worth taking a look at other possibilities.

The simplest option would be to spread the Smol dates out equally throughout the year as was shown in charts comparing the system with Napoli's. If we only cared about deviation from mean solar noon, then that might be a reasonable choice, though actual deviation from true solar noon is quite erratic, as shown below:

Example Smoitus — “Saturday Smol Days”

(pinch to zoom)

18. Final Notes / Other Ideas

During the preparation of this paper, several other whole-minute patterns were identified that are worth noting. While each is interesting, none appear strong enough to justify giving up the advantages of the Smoital system.

24 hr is not the only choice we could have made for the length of the Smol day, for example we could twice as often have days of length 24:20, or much more frequently days of length 24:39, etc. The reason to use 24 hr Smol days should be clear from the benefits of the Smoitus, but some other quick notes about its benefits compared to any other length:

24:40 / 24:35 minute days

Choosing to have short days only 5-minutes shorter than standard days has the advantage of keeping the short days not too different to standard days, while keeping them not excessively frequent.

These short days would need to occur three times as often as the previous 15-minute shorter days, which comes to 8.251998% of days.

If the schedule is chosen to have each Sunday 5-minutes shorter from say the fourth month (as measured as ¹⁄₁₂th of a Martian year) from Perihelion, up to around the second-last Sunday of the 10th month, a very compact equation of time results:

24:40 / 24:39 minute days

Going all the way down to keeping short days only 1 minute shorter than standard days has the advantage of keeping the day lengths as close as possible to the true Martian day length however seemingly requires very frequent switching between standard and short days.

Nonetheless, three interesting variants of this type are identified.

First, to calculate what percentage of days must be 24 hr 40 min vs 24 hr 39 min:

• 24 hr 39 min 35 sec 244 ms
• = 24.65979 hr
• = 24 hr 39.5874 min
• = 24 hr 40 min - (0.4126) min
• = (24 hr + 40 min) × 58.74% + (24 hr 39 min) × 41.26%

A) Clustered

As with the previous example, clustering the short days to one part of the year allows for a simple schedule, and a compact equation of time.

In the chart below, four weekdays [Sun, Tue, Thu, Sat] are 24:39 long from the third month (as measured as 1 / 12^th of a Martian year) from Perihelion, up to around the third-last week of the 11^th month, all other days being 24:40 long.

This results in the smallest range for solar noon of any shown so far, only 30.7 min of range, on par with Earth's.

B) Continuous Segments

To simplify life, one might just designate an entire chunk of the year where every day is 24 hr 39 min, and the remaining part of the year has standard days.

This would be easy for humans to work with, as there’s only 2 break-points per year where the system changes, and surprisingly, the equation of time is on par with the true equation of time (in terms of range), although the deviation from mean solar time is significant.

In the example below, the first short day occurs 154 days after Perihelion, and continues for ~275.9 days:

The usefulness of this type of schedule is much greater when attempting to optimise for a consistent time of sunrise. The example below shows the time of sunrise for a settlement at latitude 20° North, with the first short day 139 days after Perihelion.

C) Gregorian Schedule

Finally, the following schedule is a very neat way of arranging the 41.26% of short days, however it requires an Earth based calendar as the primary calendar system. The specification is very simple:

• An Earth calendar is generally used on Mars, with a calendar day removed periodically to maintain sync.
• The “skipped dates” are strategically placed to always be on a Monday, being every 5 or 6 weeks.
• Days of Monday, Wednesday and Friday are made 24 hr 39 min; other days are all 24 hr 40 min.

The outcome is:

• UTC offset can vary by slightly more than ±12 hours due to “skipped dates” being forced to Mondays.
• Mean solar clock time is tracked extremely closely at all times, always within just a few minutes.
• A correction is needed only once per ~10 years!

A full (Earth) year of such a calendar might look like the below:

Yellow: skipped dates — Blue: short day (24 hr 39 min) — Others: standard day (24 hr 40 min)

The chart below shows the resulting deviation from mean solar time over the course of an Earth year:

The reason this simple system tracks mean solar time so closely is due to the following:

• Since 2.749125% of days are skipped, the average week length is (1 - 0.02749125) × 7 = 6.80756125 days long.
• Since skipped days are always short, each week always has four long days, even if it contains a skipped day. 4 / 6.80756125 = 0.587581933…, which is very close to the previous calculated required portion of 58.74%.
• These difference of the above two numbers is 0.58758193… − 0.5874 = 0.00018193...
• I.e. Each day is 0.00018193 minutes too long on average, meaning it would take ~5,496.6 days before one‑too‑many minutes have passed, which is approximately 15 Earth years, or approximately 8.2 Mars years.

For an overview of Martian day length options and the corresponding number of timezone offsets etc, see:
•  Appendix C — Overview of Different Day Lengths.

Applicability to Other Solar System Bodies

While Mars is fairly unique among the large solid bodies of the Solar System in that almost none have a rotation speed similar to Earth’s, the idea of varying whole-minute day lengths can be applied elsewhere. One example is Ganymede, which has a sidereal orbital period around Jupiter of approximately 7.155 Earth days, and a slightly longer solar day.

A system on Ganymede in which each day is 24 hours 40 minutes, and one day per seven‑day week lasts 24 hours, could produce perpetual weekend sunlight, providing a sense of rhythm otherwise absent in these cold reaches of the Solar System. A correction would be required roughly once every two Earth years.

Although Ganymede is in a 2:1 orbital resonance with Europa, they are not synodically linked, and thus a similar system for Europa would require an independent design.

In the interest of brevity, a full analysis of other Solar System bodies is not included here.

Closing Remarks

The ideas presented here are likely only scratching the surface of the many interesting patterns that can be uncovered, and future work will undoubtedly reveal more.

The proposed approach for a gradual transition into Martian time is intended to encourage broad support, rather than leaving the challenge entirely to future Martian settlers. Back on Page 17, Antarctica was excluded from the list of time zones. This omission demonstrates how small, remote populations are often overlooked. A similar issue may be faced by Martian settlers, whose timekeeping requirements may be treated as an intellectual curiosity for Earthlings rather than a practical necessity deserving serious attention.

Supporting Smoital time gives software developers a practical advantage: in providing support for Mars, they also make Earth timekeeping systems more reliable. Without such an approach, there is a danger that Martian time will be seen as a competing demand, potentially diverting attention from long-standing problems in Earth’s own time zone support.

References

Appendix A — Smoitus with Calendar Overlay

A Smoitus, being a visualisation tool and not a calendar itself, can be integrated with a calendar overlay, for easier interpretation. The below example uses a hypothetical calendar with 12 months of 55-56 days each.

Example Smoitus — with example Mars calendar overlay

(pinch to zoom)

Appendix B — Smoitus with Calendar Overlay (Single ‘Month’)

This example shows how a small version of a Smoitus could be suitable to display alongside a single-month calendar display. The month selected is Month ‘07’ from the previous example.

When showing just one month, the map below the Smoitus could often be optimised to not show generic timezones, but the actual timezones during that month (i.e. minimal, or no striped zones to indicate DST). This has not been applied here.

Example Smoitus — with example Mars calendar overlay (single ‘month’)

Appendix C — Overview of Different Day Lengths