Add date and time utilities

[beutlich]

• Move getTime from System to Internal package and introduce a new package Time with function getTime returning a record, see .Modelica.Utilities.System.getTime() returns bad year #3143 (comment).
• Add leap year utility functions.
• Add date-time to string conversion (using strftime), see Absolute time in Modelica (datetime) ModelicaSpecification#2245.
• Add string to date-time conversion (using strptime (to be added to C-Sources since not available on all systems)), see Absolute time in Modelica (datetime) ModelicaSpecification#2245.

[HansOlsson]

The general idea is good, but:

• I don't like the abbreviations in the record (and as outputs): min, mon, ms, even if consistent with "struct tm". (As far as I understand the names should be singular: second, minute, hour, year.)
• I am unsure if we should have leap-year utilities. The reason is that it leads to people doing their own leap-year-calculations and that can lead to annoying bugs. Having a full set of utilities to avoid the need for that might be a better solution (that includes conversions between date-time and number, and handling of date-time-differences).

I tried to look at the Buildings-library. It uses full names in the records, but unfortunately it contains its own leap-year handling (hopefully correct):
https://github.com/lbl-srg/modelica-buildings/blob/master/Buildings/Utilities/Time/CalendarTime.mo

[beutlich]

I started with an operator record for TimeType to also allow addition, subtraction etc. That meant, we also would need to consider a TimeDeltaType and conversion to absolute time, which is not straight-forward. Therefore, I rejected this first idea and went for the TimeType record as absolute point in time and without numerical conversion. (String conversion is still to do, but without handling of leap-seconds).

I don't like the abbreviations in the record (and as outputs): min, mon, ms, even if consistent with "struct tm". (As far as I understand the names should be singular: second, minute, hour, year.)

OK, will rename.

I am unsure if we should have leap-year utilities.

Hm, @GallLeo what do you think? @mwetter considers leap years only in range [2020, 2030] which might not be sufficient in a general purpose library.

[sjoelund]

If you want to consider leap years, daylight savings, etc... You need to work on some absolute unit of s/etc relative from 1970... I think that's the only sane way of dealing with any kind of delta and ambiguity... Just convert between tm and time_t if you want to use that (and run the calculation in external C).

[beutlich]

Here is a first (and incomplete) draft for conversion of date/time to string. Not sure if it is good enough ❔ . Any feedback is appreciated.

[beutlich]

@HansOlsson @DagBruck @t-sommer @StephanZiegler Yesterday, I noticed by chance that there are Testing.Utilities.Time.{DateTime, Duration} available in Dymola as operator records. This is exactly the way I wanted to go here for MSL, too. I believe these utilities came up as necessary side-product when meaasuring time in Modelica. Now, that I am aware of this library, I am also biased with the further development. My question is, if you could think of contributing or sharing Modelica code for further development as OSS, such that I am sure, no copyright will be violated?

[m-kessler]

We would be happy to move the operator records from the Testing library to the MSL.
@beutlich How shall we proceed? My recommendation would be, that I first push a purely MSL-based version of the operator records to this pull request. Then we can review the code and merge it with your work.

[CLAassistant]

All committers have signed the CLA.

[beutlich]

@m-kessler Thank you for the generous offer. I rebased the commits of this PR on master and resolved the merge conficts. This PR branch is now ready to be used. I added you as contributor (with access role = Triage) such that you can directly push to this branch (hopefully).

I already created a TimeType record. This can be now enhanced by using the two different operator records from the Testing package. It would be good if we can use the exsting names of the TimeType record components (which are different than the Testing package.)