SUMMARY

The Modelica language is nicely positioned as a lingua franca to describe dynamic systems accross many domains. Unfortunately, Modelica's strong ties to the SI system of units are inhibiting a wider adoption of the language for non-technical modeling needs, e.g., in the social sciences. The inductive and aggregate nature of models in the "soft sciences" calls for better assistance of tools to catch "dubious" or even outright wrong equation formulations. Without a clearly specified way to introduce and use custom derived and/or base units, Modelica will likely fail to appeal to these domains.

This proposal calls for Modelica to better address such needs and points out that this will not at all mean to sidestep SI units or engineering rigor. Accomodating the needs of non-technical domains should not simply be left to tools, but clearly be embraced by Modelica in general. There is much more to be gained than to be lost by doing so.

Introduction

In a paper published in the proceedings of the 13th International Modelica Conference 2019 Michael Tiller points out the broad applicability of Modelica:

"Modelica was designed from the outset to be domain neutral. The hope was that the foundations of Modelica were sufficiently complete that it could not only be used to model the wide range of engineering related systems that the designers were familiar with but that it was universal enough to model nearly any system from any domain, even those unfamiliar to the language designers. The wide range of domains that Modelica has been applied to over the last 20 years is a testament to the success of these design goals." [1]

A broad modeling paradigm used predomiantly in the social sciences certainly is system dynamics introduced by Jay W. Forrester, for which since 2002 there exists a dedicated SystemDynamics library by Cellier and Fabricius. Introducing newcomers to system dynamics in the library's user guide, Prof. Cellier enlightens us with the following observation:

"System Dynamics modelers are generally quite 'generous' (sloppy) in the use of concepts." [2]

Modeling and simulation in "soft" scienes certainly can appear overly "generous" or even "sloppy" reminding us of the old joke:

In physics, you have 3 laws of motion that explain 97% of all phenomena. In finance, it is the other way around.

Nonetheless, as a long-time practitioner of system dynamics and author of the BusinessSimulation library for Modelica [3], I am tempted to counter Prof. Cellier's observation with one from my own experience. While system dynamicists may appear generous with "concepts", they most often are rather rigorous in their use of unit checking to detect formulation errors, even though there certainly is a lot of confusion as to what really are units and quantities—the latter typically never appear in dedicated SD software tools.

Unfortunately, while Modelica naturally has strong ties to SI units, it is very hard to extend their "physical rigor" to the softer sciences' needs—which may explain, why SI units do not play a major role in SD software tools. Let's look at two typical examples to highlight the current state of affairs with regard to units and non-technical domain modeling.

Modeling supply and demand without any units

Referencing Michael Tiller [1] again, who gives practical examples on how to model "supply and demand" in Modelica, we observe the following types for the concepts "price" and "sales volume":

type Price = Real(min=0, quantity="Price"); 
type SalesVolume = Real(quantity="Units");

While this example makes use of the quantity attribute available for the predefined type Real, it remains completely "silent" with regard to the unit attribute, which by inheritance therefore remains an unchanged unit = "" empty string, which may allow tools to infer what likely cannot be inferred at all in economic models.

The quantity attribute is a nice way to categorize variables and even puts uniqueness requirements to connection sets, but Modelica's implementation of quantities appears insufficient to detect more serious equation errors. In other words, Tiller's solution to not make use of the unit attribute completely forfeits unit checking and I may add that a choice of quantity like "units" appears rather ad hoc to me.

Modeling world dynamics with units that simply let seconds mean years

Cellier and Fabricius [2] use their SystemDynamics library to implement the famous World2 model by Forrester. Let's look at how parameters (example taken from Scenario_1) are defined and at the corresponding experiment annotation:

model Scenario_1 "1st Scenario"
  parameter Real Population_0 = 1650000000.0 "World population in 1900";
  parameter Real Pollution_0 = 200000000.0 "Pollution in 1900";
  parameter Real Nat_Resources_0(unit = "ton") = 900000000000.0 "Unrecoverable natural resources in 1900";
  parameter Real Cap_Invest_0(unit = "dollar") = 400000000.0 "Capital investment in 1900";
  parameter Real CIAF_0 = 0.2 "Proportion of capital investment in agriculture in 1900";
  parameter Real BRN(unit = "1/yr") = 0.04 "Normal birth rate";
  parameter Real CIAFN(unit = "dollar") = 0.3 "CIAF normalization";
  parameter Real CIAFT(unit = "yr") = 15.0 "CIAF time constant";
  parameter Real CIDN(unit = "dollar/yr") = 0.025 "Normal capital discard";
  parameter Real CIGN(unit = "dollar/yr") = 0.05 "Normal capital generation";
  parameter Real DRN(unit = "1/yr") = 0.028 "Normal death rate";
  parameter Real ECIRN(unit = "dollar") = 1.0 "Capital normalization";
  parameter Real FC(unit = "kg/yr") = 1.0 "Food coefficient";
  parameter Real FN(unit = "kg/yr") = 1.0 "Food normalization";
  parameter Real Land_Area(unit = "hectare") = 135000000.0 "Area of arable land";
  parameter Real NRI(unit = "ton") = 900000000000.0 "Initial natural resources";
  parameter Real NRUN(unit = "1/yr") = 1.0 "Normal resource utilization";
  parameter Real POLN(unit = "1/yr") = 1.0 "Normal pollution";
  parameter Real POLS = 3599900000.0 "Standard pollution";
  parameter Real Pop_dens_norm(unit = "1/hectare") = 26.5 "Normal population density";
  parameter Real QLS = 1.0 "Standard quality of life";
  ...
  annotation( ...
    experiment(StartTime = 1900, StopTime = 2100), ...
  );
end Scenario_1;

While the authors have taken care to make use of the unit attribute, their use runs into all kinds of issues:

All Modelica models run in seconds s and thus the experiment annotation, which only allows to take numerical values for time measured in seconds, is strictly false in equating 1.9 ks with the year 1900.
"yr" (as abbreviation of "year") is (still) not a widely accepted unit-string in Modelica (see #2835).
"hectare" is not introduced as displayUnit for the known SI quantity Area and "ton" is never introduced as a displayUnit for Mass.
We need to assume that everything that is not introduced as a derived unit from a known base unit is a custom base unit, so "hectare", "ton", "yr", and "dollar" could be interpreted as such—without there being a guarantee for this kind of interpretation across tools to my knowledge.
While monetary quantities have their own rates of flow, e.g, unit = "dollar/yr", the population remains a Real with unit = "" and accordingly we never know, whether the "normal birth rate" is a fractional or an absolute rate of growth: BRN(unit = "1/yr"). Seemingly, accounting for "money" is more important than accounting for "people."

Desiderata for accomodating "non-technical" modeling paradigms

From the examples given above, we see that the use of the unit attribute within the restrictions of the Modelica unit framework is rather difficult for modelers coming from the social and other "soft" sciences. On the other hand, not assigning units or careless use of unit = "1" forfeits many possibilities offered by Modelica to detect errors in "creative equation formulations." So here is a tentative list of what "we" desire:

Convenience

The use of displayUnit is excellent for SI units and that kind of convenience should carry over especially to other units of Time, e.g., we want to conveniently enter "weeks" or "months" or "years"—irrespective of the undisputed ambiguity associated with these units. It seems rather safe to assume, that not many modelers from non-technical domains will want to enter fractional birth rates for a population as "per second" or "per day" values. People, who enter time spans in years will likely want to be "correct on average" with a real calendar in mind (see mean Gregorian calendar year below).

Rigor

Non-technical modeling by necessity will often be rather "phenomenological" and "inductive." This makes unit checking even more desirable than in technical domains. At the very least, we should be able to distinguish fractional rates, e.g, 1/s from absolute ones, e.g., people/year or USD/month. But more generally, it should be possible to have additional, non-SI base units as to distinguish 1 from 1 person or 1 unit sold. Unit checking prevents us from numerical errors introduced by conflating ft with m, but in the same vein, it will be tremendously helpful to distinguish a conversionRate given in EUR/USD from the one given in USD/EUR.

Model reuse

Modelica's object-oriented design is a much needed—and still innovative—addition to a social-science modeler's tool box. Designing components with parameters and constants with more flexible (non-SI) units in such a way that their reuse is not impeded is not an easy task.

Compatibility

Changes and additions to Modelica to accomodate non-technical modeling should ideally not be tool-specific, but tool-agnostic. Modelica should be attractive to modelers from non-technical domains, not simply a "subset of the tools." Changes and additions should not break existing code, if possible.

Proposals

Proposal 1: Better support for other derived units of time

If not even modelers from the ETH Zürich convert years into seconds, then likely not too many others will. Acknowledging the imprecision for anything beyond day, I would propose that the Modelica language and the MSL should embrace week [wk], month [mo], year [yr] or even quarter year [qtr] with the following pragmatic average definitions:

1 week [wk] = 7 d = 604 800 s
1 year [yr] = 365.2425 d = 31 556 952 s
1 month [mo] = 1/12 yr = 365.2425 * 24 * 60 * 60 /12 s = 2 629 746 s
1 quarter year [qtr] = 3 mo = 7 889 238 s

The Modelica Specs should provide a general way, e.g., an annotation, to provide experiment annotations using derived units of time as displayUnit such as the ones given above. It should be possible to show time series plots in years instead of seconds as to not lure modelers into equating seconds with years as Cellier and Fabricius have done.

This proposal acknowledges that the modern, Gregorian calendar is close to being universal and that the pragmatic use of the Gregorian mean calendar year in non-technical modeling domains is rather widespread, making this a very convenient and attractive addition to the Modelica Specs and Modelic's non-SI units. Being able to use wk, mo, and yr next to min, h, d will greatly enhance the user experience for modelers entering rates of flow or units of time in non-technical models. The benefits of offering these non-SI units of time should clearly outweigh the downsides of making the "mean year" an addition in favor over the "tropical year" or the "common year". Entering rates with 365 days in mind is rather straight forward using displayUnit = "1/d".

EDIT As explained below, the physical definition of an average Gregorian year is a constant that will not change in meaning. Adding calendar time definitions for StartTime and StopTime should imho not interfere with this constant definition of a derived unit of physical time. One can always add physical time spans to calendar dates or go from calendar dates to physical time spans, but calendar time spans are ambiguous.

For now, all that is asked for is the addition or admissibility of derived units for physical time that likely will not preclude addition of calendar time functionality later on.

Proposal 2: Clearly define ways to add custom derived units and conversions

There should be a general way to add custom derived units like hectare or ton in the World2 model and the flow rates thereof, e.g., hectare/yr and ton/yr. The need for derived unit definitions and the provision of conversion factors at the level of a library becomes especially obvious for entering rates of flow in non-SI units.

What about counting units? The SI see all of these as "subsumed" by having "1" be a base unit, but this fails to distinguish truly unitless ratios like kg/kg or m/m from counts. Counting is ontologically different from measurement on a real scale and unit="1" never makes it apparant anywhere, that we are referencing multiples of quantums like bit or byte or simply each meaning "elementary units of ...", where we can never have less than 1 quantum of something. [4, 5]

Sine we have:

1 mol = N_a each

We could introduce each as a derived unit for AmountOfSubstance measured in mol, but Avogadro's number introduces numerical noise that might best be avoided. Better then to make each a separate base unit.

EDIT I should probably make it clearer that in adding the base unit each we are strictly speaking adding a derived unit of the SI base unit 1 for the sake of better unit checking, e.g., distinguish throughput from truly dimensionless rates.

Proposal 3: Cleary define ways to add custom base units

Flater [6] proposes to clearly distinguish ratios from counts as to allow software tools to better assist in detecting errors in formulations. Since it likely is not really possible to have type hierarchies as suggested by Flater, unit checking in Modelica will only be able to work "its magic" once we are enabled to introduce separate base unit definitions.

As noted above, rigorous unit checking should distinguish absolute rates of flows from truly dimensionless rates of flows, e.g., fractional rates, in the same way a chemist will in using MolarFlowRate measured in mol/s. It seems obvious to distinguish counting discrete entities and substances from measurement. While we might want to introduce people and people/s or vehicles and vehicles/s, this flexibility might hamper reusability and model compatibility? One might thus, as a minimal addition, introduce each as a base unit that is somewhat comparable to the chemist's use of the mole:

base unit name: "each"
description: "Number of elementary entities of ..."

(Note, that Flater goes further in making mol be a simple prefix, i.e., corresponding to Avogadro's number N_a, for a counting number that is an extension of 1 as a base unit.)

The need for custom base units becomes even more evident for money and currency. Currencies will have time-dependent conversion rates and cannot be simply set up using static displayUnit conversion factors. Monetary value is nowadays not necessarily tied to a physical entity, e.g., a coin and thus a quantum like 1 cent, and thus money will not be a derived unit of each. Simply using dimensionless unit = "1" will not be helpful in more complicated financial models, where it may be easy to conflate conversion factors if units are no guidance.

I would propose using ISO 4217 as guidance for introducing currency units, e.g., USD,EUR, JPN, CNY, GBP, etc. One could also "abuse" the currency code XXX to mean "no specific currency," when a modeler wants to distinguish monetary values from other values, but does not want not indicate any specific currency.

Discussion

The proposals to me seem like a minimally invasive modification of current Modelica specifications, which will have much more benefits than downsides. Note, that by a "global switch," we might at any time reduce all custom units to SI units, e.g., 1. The addition of custom base unit definitions can greatly help to make greatest possible use of Modelica's support for unit checking to detecting errors.

While Modelica's generous use of Real for all units including the mole is not able to unambiguously address "quantals," the use of mol and each might remind modelers of the fact that in reality any "true" representation of a quantity value would be an Integer.

References

[1] M.M. Tiller, “Modeling Supply and Demand in Modelica,” in Linköping Electronic Conference Proceedings, Linköping University Electronic Press, Feb. 2019. doi: 10.3384/ecp19157365.

[2] F.E. Cellier and S. Fabricius, "SystemDynamics: Free library for modeling according to the principles of system dynamics of J. Forrester,” version 2.1.2, Feb. 7, 2023. https://github.com/modelica-3rdparty/SystemDynamics

[3] G.W. Reichert, "Hierarchical, Component-Based Modeling Using the Cyber-Physical Modeling Language Modelica," in Conference Record of the 2022 System Dynamics Conference, Frankfurt, Germany, System Dynamics Society, 2022. https://proceedings.systemdynamics.org/2022/papers/P1332.pdf

[4] G. Cooper and S.M. Humphry, “The ontological distinction between units and entities,” Synthese, vol. 187, no. 2, pp. 393–401, 2010. doi: 10.1007/s11229-010-9832-1.

[5] D. Flater, D. Foxvog, and R. Kacker, “A unified model of core metrological concepts,” 2023. doi: 10.13140/RG.2.2.10015.33445/1.

[6] D. Flater, “Architecture for software-assisted quantity calculus,” National Institute of Standards and Technology, Dec. 2016. doi: 10.6028/nist.tn.1943.

EDIT (2023-10-25): Upon closer reflexion, it seems most sensical to use an average calendar year definition as a good compromise. It is intuitive for longer term simulations with negligible error, widely applicable and people, who prefer 365 or 360 day definitions, can easily enter such rates or convert spans.

@henrikt-ma what do you think?

I'd say most of this proposal is very much in line with what we'll soon have in System Modeler. That said, I think it is too early for the language group to go into detailed discussions about units for non-technical domains until we have landed a good design for checking the units seen in the MSL today, or at least most of them. When we get there, I'll be happy to demonstrate what we've done to cater for this need.

However, as you recently noted in the email to MAP-Lib, it would be sad to paint ourselves into a corner where all we can reason about is dimensions rather than units. Fortunately, we (System Modeler) already have a system capable of checking units rather than dimensions in place, so I think we'll be able to spot bad designs in this regard. Regarding the present issue, for example, this means that we shouldn't be looking for a system that can only verify that a "dollar" and a "cent" have the same dimension, but a system that can detect that there's a non-trivial conversion factor between two compatible units. Actually, as checking units rather than dimensions almost comes for free, I'm surprised that this is not what other tools have already implemented.

But isn't it also kind of sad to note that more than 20 years since the System Dynamics library was released, it is still not widely acceptable or possible to have an average year definition in place that allows displayUnit = "yr" so that one will not be lured to follow the (imprecise) example by Cellier and Fabricius? Running climate models with relevant rates entered per second?

As early as 2014, Mohr and Phillips observed the shortcomings of the use of dimensionless units in SI:

Mohr and Phillips, Dimensionless units in the SI

and interestingly right from the very start, the Business Simulation library has (intuitively) tried to follow some of the recommendations given by Flater in 2017 as to distinguish "counting units" from "ratios" in a first step so that adding angular_velocity [rad/s] and entity_throughput [1/s] and frequency [Hz] will not give something nonsensical that has unit = "Hz" (which tells us that units presently maybe fail to tell the whole story?).

Sadly, two years have passed since issue #2835 surfaced in this group and I still do not know how to "properly" (acceptable by most tools) provide type declarations that are a bit more intelligent than simply making everything that is not to be found in the SI simply a dimensionless quantity ...

Calendar Time and Physical Time

From our telephone conversation I take away that custom definitions for other units of time require more careful thought. Explicitly, calendar time was set against physical time. As a long time user of Wolfram Mathematica I am, of course, aware of all the subtleties when dealing with time. But even in Wolfram Mathematica the following (physical) definitions for the quantity time will to my knowledge always hold true:

UnitConvert[ Quantity[ 1., "AverageYear"], "Days" ] (* 365.2425 days *)
UnitConvert[ Quantity[ 1., "AverageMonth"], "Days" ] (* 30.4369 days *)
UnitConvert[ Quantity[ 1., "Year"], "Days" ] (* 365. days *)
UnitConvert[ Quantity[ 1., "Month"], "Days" ] (* 30.4167 days *)

Why not—in a first step—follow that example and introduce such derived units of time or at least allow to do this in a standardized way? These will be physical quantities and their definitions are exact—constant—amounts of seconds, which is what typically counts.

To me, exact calendar dates are best given as a list {y, m, d, h, m, s} and then certainly adding an amount of time to a defined date can either be done with calendar time in mind or with physical time in mind as given above.

Adding physical quantities of time defined as above to a date is unambiguous: We are adding clearly defined amounts of seconds. But conflating the meanings of calendar durations, e.g., 1 month with the static physical definitions adds quite some confusion:

startDate = Interpreter[Date] @ "Februray 1, 2024"
DatePlus[ startDate, { 1, "Months"} ] (* Fri 1 Mar 2024 *) 
DatePlus[ startDate, Quantity[ 30.4167, "Days" ] ] (* Sat 2 Mar 2024 *)

Wouldn't separating these definitions by using the list format for all calendar related references (dates and durations) avoid pretty much most if not all of the ambiguity, e.g., adding {0, 1, 0, 0, 0, 0} to {2024, 2, 1, 0, 0, 0} can be done unambiguously following some modulo arithmetic for calendar time? What reasons are there really against introducing precise physical definitions for Gregorian average year and common year (and accordingly for months) and allowing those as derived units of time as soon as possible (ideally also to set the experiment annotation)?

To me, exact calendar dates are best given as a list {y, m, d, h, m, s} and then certainly adding an amount of time to a defined date can either be done with calendar time in mind or with physical time in mind as given above.

I would have preferred using a Modelica built-in record for calendar time, and I would have liked the MSL to provide basic functions for operating on such records, for example adding time offsets, or finding the difference between two calendar times. I believe that the record should also include time zone offset, so that the ISO 8601 date time 2023-11-13T16:31:15+01:00 could be directly translated to/from Modelica. Maybe one also needs a daylight savings flag to avoid ambiguity on the night of the year when 02:30 happens twice?

Any chance there could be a standard way of storing the epoch within a simulation result, or would tool vendors need to resort to vendor specific tricks such as embedding information in the description string stored with time?

I suppose the epoch should be stored with the other experiment options in the experiment annotation, but maybe that would be too restrictive if we think of needs such as expressing the time when model translation was initiated/completed, or when simulation starts?

Before diving deeper into the design, however, I think we need to make sure that there would be enough interest from enough tool vendors to make the effort in the end to support working with calendar dates. I mean, just adding the possibility to set up the epoch in the experiment annotation, and then write out calendar time on the time axis of plots would require a significant effort just to make the plots look nice for both short and long simulations. Then, there are probably several more places in tool-specific workflows where the information about the epoch should be passed along and be taken into consideration.

To me, exact calendar dates are best given as a list {y, m, d, h, m, s} and then certainly adding an amount of time to a defined date can either be done with calendar time in mind or with physical time in mind as given above.

I would have preferred using a Modelica built-in record for calendar time, and I would have liked the MSL to provide basic functions for operating on such records, for example adding time offsets, or finding the difference between two calendar times. I believe that the record should also include time zone offset, so that the ISO 8601 date time 2023-11-13T16:31:15+01:00 could be directly translated to/from Modelica. Maybe one also needs a daylight savings flag to avoid ambiguity on the night of the year when 02:30 happens twice?

Any chance there could be a standard way of storing the epoch within a simulation result, or would tool vendors need to resort to vendor specific tricks such as embedding information in the description string stored with time?

I suppose the epoch should be stored with the other experiment options in the experiment annotation, but maybe that would be too restrictive if we think of needs such as expressing the time when model translation was initiated/completed, or when simulation starts?

Before diving deeper into the design, however, I think we need to make sure that there would be enough interest from enough tool vendors to make the effort in the end to support working with calendar dates. I mean, just adding the possibility to set up the epoch in the experiment annotation, and then write out calendar time on the time axis of plots would require a significant effort just to make the plots look nice for both short and long simulations. Then, there are probably several more places in tool-specific workflows where the information about the epoch should be passed along and be taken into consideration.

Wouldn't this be similar to having a display time unit and a basic unit of time, i.e., while we can output or input a time stamp for values with offsets (+01:00 or A), to avoid any ambiguity internally it should clearly be UT or UTC and in that time reference 02:30 will not happen twice—02:30 is an artifact as it will be 02:30B and 02:30A, respectively? There should be some notion of an "absolute" or "base" time reference.

Now, what I wrote has simplified matters and addressed a simulation experiment separated from systems with a real time reference frame and synchronous simulations. While completely out of my depth here, I would imagine that "digital shadows" (linking a simulation to a real time sensor) or "digital twins" (additionally allowing links to real time actuators) will need clocks. How to map clock ticks to calendar time in an unambiguous and precise way? Will leap seconds need to be accounted for—to my knowledge leap seconds cannot be predicted with certainty well in advance?

As a quick addendum:

I assume that for most purposes the classical Newtonian model of space and time is sufficient. Accordingly, simulations will typically assume a universal clock and do not account for relativistic effects, as these effects are negligible for the scenarios being modeled.

I am not so sure about distributed systems and synchronization, e.g., synchronization protocols like the Network Time Protocol (NTP)?

To me, exact calendar dates are best given as a list {y, m, d, h, m, s} and then certainly adding an amount of time to a defined date can either be done with calendar time in mind or with physical time in mind as given above.

I would have preferred using a Modelica built-in record for calendar time, and I would have liked the MSL to provide basic functions for operating on such records, for example adding time offsets, or finding the difference between two calendar times. I believe that the record should also include time zone offset, so that the ISO 8601 date time 2023-11-13T16:31:15+01:00 could be directly translated to/from Modelica. Maybe one also needs a daylight savings flag to avoid ambiguity on the night of the year when 02:30 happens twice? Any chance there could be a standard way of storing the epoch within a simulation result, or would tool vendors need to resort to vendor specific tricks such as embedding information in the description string stored with time? I suppose the epoch should be stored with the other experiment options in the experiment annotation, but maybe that would be too restrictive if we think of needs such as expressing the time when model translation was initiated/completed, or when simulation starts? Before diving deeper into the design, however, I think we need to make sure that there would be enough interest from enough tool vendors to make the effort in the end to support working with calendar dates. I mean, just adding the possibility to set up the epoch in the experiment annotation, and then write out calendar time on the time axis of plots would require a significant effort just to make the plots look nice for both short and long simulations. Then, there are probably several more places in tool-specific workflows where the information about the epoch should be passed along and be taken into consideration.

Wouldn't this be similar to having a display time unit and a basic unit of time, i.e., while we can output or input a time stamp for values with offsets (+01:00 or A), to avoid any ambiguity internally it should clearly be UT or UTC and in that time reference 02:30 will not happen twice—02:30 is an artifact as it will be 02:30B and 02:30A, respectively? There should be some notion of an "absolute" or "base" time reference.

Now, what I wrote has simplified matters and addressed a simulation experiment separated from systems with a real time reference frame and synchronous simulations. While completely out of my depth here, I would imagine that "digital shadows" (linking a simulation to a real time sensor) or "digital twins" (additionally allowing links to real time actuators) will need clocks. How to map clock ticks to calendar time in an unambiguous and precise way? Will leap seconds need to be accounted for—to my knowledge leap seconds cannot be predicted with certainty well in advance?

To me it makes sense to consider different variants of time:

Pure relative time - especially for simulated time less than a year
Relative time with standard years; where 1yr=365.2425 days (right?)
Absolute time with an epoch, but not fine-grained enough that leap-seconds matter - or possibly after 2035 if the plan to abandon leap-seconds is followed and nothing else replaces it
Absolute time with an epoch and leap-seconds (or similar changes in the future)

If we have a sufficiently general epoch-specific handling we can handle all of these cases, e.g.:

epochTime=""
epochTime="standardYear"
epochTime="simple 2023-11-13T16:31:15+01:00"
epochTime="2023-11-13T16:31:15+01:00"

(Well, most people will have a more convenient and less random epochTime.) Relativistic effects would require a lot more (possibly a more fundamental redesign.)

Added: We might also consider a variant with astronomical year ("Julian year") as in #2835 which is 365.25days. (Astronomers also have the year 0 for simplicity.)

modelica / ModelicaSpecification

The Mole Day Proposal: Modelica should better accommodate the modeling needs of non-technical domains #3425