The Asgardian calendar is available at :

https://asgardia.space/en/calendar

This is an excellent piece of work, the site and it's interactive presentation of the Calendar is excellent. Given this success, the question must be asked. Is this the final version or can we build on these solid foundations and further improve the calendar? To make it universal and able to convert between all calendars that Asgardia may need in the future. That would seem to be to be the logical way forward. What must be done to extend the calendar to achieve these goals?

A note on modelling

A calendar is a model of reality, normally created for coordination and predictive purposes. Calendars can be used to predict when is the best time to plant and harvest crops, when animals migrate and so when to hunt them and how much daylight there will be at a certain time of the year. That is assuming a solar based calendar, moon based calendars can be used to predict tides and other animal behaviour. Calendars can also be used to coordinate activities. There can be multiple calendars, taking different cycles into account, so conversion between calendars is required.

Calendars are about astronomical cycles, such as the time a planet takes to orbit it's star or a natural satellite takes to orbit it's planet. Planets spin, so the number of spins (days) in a cycle is normally what we are interested in, in particular the timing and duration of day and night. The fundamental problem is these phenomena are natural and unfortunately no orbit of any body around any other will be an exact number of days. Hence if we assume integer numbers of days per year we need to add (or subtract) an extra one every so often to keep the model reasonably close to the astronomical reality. Historically we have used simple rules to do this, but this is not perfect and requires revision periodically.

So, a parameterised universal leap year calculation that minimises the drift of days in a year, makes sense. The only parameter required is the length of the year in local days as a real number. The start of Era may or may  be a leap year itself.

In summary, a calendar is the synchronisation of 2 cycles by inserting 'leap' periods. On other planets a leap second would be required too every so often, given the second is a fraction of an Earth day, and it is sensible to keep the SI units.

Structure of dates

A calendar minimally requires 2 numbers to make it work, the number of planetary rotations in the orbit (the Earth around the Sun for example). In essence, we are trying to maximise the usefulness and predictive capability of the model without making it too complicated (and keeping the number reasonably small and tractable). So we could simply say a date is Year.Day (with 365.24219878 days in a year approximately on Earth).  To turn this into 2 integers we require an day to be added at the end of the year periodically, called a leap year. If it were not added at the end of the year the day numbers would jump about between normal and leap years, which is highly undesirable.

Now, traditionally on earth we have tried to accommodate lunar cycles into this scheme too, calling them months. This does not 'fit' very well mathematically. However, as humans we find the additional concepts of months and weeks convenient for our activities. To justify this we think of months as approximating lunar cycles (but the drift makes this rather impractical) or with reference to the appearance of the 'fixed' stars, on which our brains project patterns, a sequence of constellations as they are called. Historically (in the West), this has resulted in a calendar with 3 cycles, years, months, and days (or 4 cycles with weeks). We are so familiar with this convention, it seems 'natural', it is actually just locally convenient and historical.

Naming

With the introduced concepts of months and weeks, and thousands of years of tradition, we like to name these concepts and number them from one. This works reasonably well on Earth, however, if we are to keep 28 day months on other planets then the number of months required becomes less manageable as we get further from the sun. On Uranus this would require approximately 741.298, 28 (local) day months which is inconvenient. Even on Jupiter this would be 154.627 months in a year. Mars is not too bad at 23.878 months per year. Week days, if kept to 7 days could retain the current names, but it might be desirable to use culturally and historically neutral names.

Recommendation, for consistency number these concepts (month days and week days). For ease of conversion from calendar to calendar, start the numbering at zero. A competition for additional naming of months/week days can be held when a new planet is colonised if sensible, but humans on other planets need not know your local naming conventions (just the year and day length) to be able to communicate and convert dates if the names are underpinned by numbers.

Where will we live

Now with reference to the other planets, the outer planets are gas giants, so we are unlikely to live on the surface of these planets. We may well live on the satellites though. So, we do not necessarily need to use the day length of the planet as the day length we adopt. We will not be interested in agriculture on the surface of the satellite, as we will live in artificial environments. So the day length can be either local to the satellite (if tolerable for humans) or we could simply adopt Earths day length and ignore light/dark period duration (in so much as that matters given the sun is distant).

For the Earths Moon, a 'local' day is about 2 weeks, so ignoring local days and adopting Earths day length makes sense, indeed, just adopting Earths solar calendar would be sensible. On Mars, the local day length is 24.65979 hours, so we could adopt the local day and year and have a completely local Martian calendar that would be tolerable for humans. The year is approximately 668.591 local days long so there would be a lot of leap years, but this does not really matter.

For artificial space stations, adopting the calendar of the planet being orbited makes sense. For everyday usage (around say Jupiter), using the Earth calendar internally would be convenient (especially given the days are so short).

So, in conclusion there are some choices about what is convenient for humans to adopt as a convention in new places to live. A generic model can be parameterised to take into account these variants. The only fundamental concepts for a calendar are the longer period (for example the year), and the shorter period (the day). The most basic, but complete calendar is then Year+Day. Other formats to include months and weeks can then be accommodated on top of this, again with automated conversion between formats.

Include time of day

When the length of a day varies between planets converting date/times between the two planets means that the time of day will change. For example 10:00 on Earth (assume UTC) would be some other time on Mars, assume conveniently it is also 10:00 there. A meeting is held (ignore light delay inconvenience). We want to have another meeting the following week. On Earth that time will again be 10:00 (assuming Earth time is 'dominant'), but as a Martian day is 0.65979 hours longer we need to subtract that from the meeting time, so 7 x 0.65979 x (24 / 24.65979) = 4.494958. The Martian time for the meeting would be approximately 05:30 in the morning. Similarly, if the Martian time were 'dominant' then the earth time would be later in the day. When scheduling monthly, this would push the meeting into the 'previous' day on Mars. So, it is inaccurate to model just the calendar, the relative length of a day must also be taken into account. There are other confounding factors. Such as timezones, daylight savings and the relative light delay between planets. For this reason, it makes sense to reduce the number of variables. We can do nothing about relative light delay. However, we can do something about timezones and daylight savings, namely simply don't have them. Use a single meridian (on Earth UTC) as the single time for everywhere. This would mean that night and day start are at different times of the day in different places on Earth. So the local night would be from 06:33 to 18:33 (not exact) if you live in Fiji for example. You will get used to it. The first settlement on another planet would establish the 'base' meridian.

Yet another issue is the year relative to day/night cycles and the year relative to the 'fixed' stars. They are not the same, though conveniently on Earth there is only about 20.34167 minutes difference see

https://en.wikipedia.org/wiki/Sidereal_year.

Adopting a Sidereal year as a standard would be more universal than a Solar year, and with the adoption of a standard meridian, this would mean the day night start cycles would vary everywhere. Again, this would be strange at first, but our descendants will adapt and for a multi-planet species that will be simpler. We would have to use a calendar conversion app to work out data/times and their conversion, but we cannot be a multi-planet species without technology, so that will simply be taken for granted by our descendants.

N body problems and Ellipses

All orbits are ellipses. All orbits are around a common centre of gravity. Any solar system is essentially an N body problem and closed form solutions do not exists, just numerical solutions

https://en.wikipedia.org/wiki/Three-body_problem.

Elliptical orbits will also make the duration of seasons vary in length over time and the N body dynamics, especial in systems with multiple heavy bodies, such as multiple stars, will make calendars inaccurate after a time.

So the modelling above inherently has a chaotic element. This cannot be avoided, however humans will probably choose to live in relative stable solar systems for the most part.

There are also 'wandering' planets, bodies that do not orbit a star. These bodies will still have a day relative to the 'fixed' stars but no astronomical year. A 'year of convenience' might be appropriate here, choose a convenient year length relative to the day length or simply adopt a calendar from elsewhere, such as Earth, as the day length may not be interesting (it is always dark).

Conclusion

Calendars used by a space fairing race need to be designed based on a generic and flexible scheme. Automated conversion between any 2 calendars is essential. There are local choices to be made too. Calendar development is a process, but we can help future generations by trying now to make this as simple and consistent as possible.