Time and Time Standards

The time standards supported in DME Component Libraries are listed in the following table. All of these time standards are accessible via static properties on the TimeStandard class.

You can extend DME Component Libraries with additional time standards by creating an instance of TimeStandard to represent the new standard and registering conversions to and from at least one of the existing time standards with the TimeStandardConverter. By defining just one conversion to an existing time standard and one conversion from an existing time standard, DME Component Libraries will deduce how to convert your new time standard to or from any time standard that it knows about.

A measurement scale specifies additional divisions based on the fundamental unit of measure which can be used to express the measured quantity. The time scale adopted for the class library uses the standard day consisting of 86400 seconds as the major division and the second as the minor division for expressing a quantity of time. This approach ensures that instants and spans of time can be represented with a high degree of precision.

As with the measurement of any physical quantity, the measurement of time is made between two identified markers (or epochs) and produces a span (or duration) expressed according to the measurement scale. Establishing one of the epochs produces a common time scale or calendar system against which other epochs (or dates) can be referenced. DME Component Libraries uses the system employed by the astronomical community, which defines an astronomical Julian date as a continuous count of days that have elapsed since an initial epoch defined as noon Universal Time, Monday, 1 January 4713 BC of the proleptic Julian calendar.

The JulianDate type represents an epoch as the integer number of days and the decimal number of seconds of a day which have elapsed since the initial epoch. All JulianDate objects must be expressed in a specific time standard. DME Component Libraries can convert a JulianDate between any of the available time standards, as in the following example:

JulianDate dateInUtc = new JulianDate(2454245, 0.0, TimeStandard.getCoordinatedUniversalTime());
JulianDate dateInTai = dateInUtc.toTimeStandard(TimeStandard.getInternationalAtomicTime());

Similarly, the Duration type represents a span of time as the integer number of days and decimal number of seconds of a day. However, unlike the JulianDate type, specifying a time standard when defining a Duration is optional. If a Duration does not have a time standard, it is assumed to match the time standard of any Julian dates with which it is used. For example:

Duration oneDay5Seconds = new Duration(1, 5.0); // time standard not specified
JulianDate now = new JulianDate(2454245, 0.0, TimeStandard.getInternationalAtomicTime());
JulianDate oneDay5SecondsFromNow = JulianDate.add(now, oneDay5Seconds);

In this example, the Duration is assumed to be TAI for purposes of the addition, and oneDay5SecondsFromNow will be TAI as well. If oneDay5Seconds were added to a JulianDate with a different time standard, it would adopt that other standard.

If a Duration does have a time standard, any arithmetic involving the duration will be done in that time standard. That is, if you add a Duration to a JulianDate, the JulianDate will be converted to the Duration time standard, the addition will be performed, and the resulting JulianDate will be converted back to the time standard of the original.

Since time is used nearly everywhere in DME Component Libraries, it is important to note the impact of time conversions on performance. Conversions involving look-up tables for leap seconds or other such offsets can impact performance for calculations where the conversion may potentially be recomputed several times for a given evaluation. In order to correctly perform operations on different times in different standards, DME Component Libraries converts each time to its corresponding ArithmeticSafeStandard (get). This avoids the problem posed by durations of time including leap seconds or other irregularities.

In order to improve performance, it is almost always best to convert times to an arithmetically safe time standard prior to performing any operation with DME Component Libraries. In general, the arithmetically safe standard for CoordinatedUniversalTime (get) is InternationalAtomicTime (get) and is used internally to perform calculations. So, in order to increase performance in many cases, it is usually best to convert to TAI prior to calling any calculations or setting up time intervals with DME Component Libraries.

Specifically, one place which sees this a lot is the Sgp4Propagator which performs its calculations using TAI. If the user asks for a propagation over an interval and timestep specified in UTC, the system interprets this to mean that the steps should be taken in the UTC timescale. However, in order to compute the correct timespans (potentially propagating through leap seconds), the system will convert to TAI in order to compare times. Since the length of a second is different in various time standards (specifically: InternationalAtomicTime (get) vs. UniversalTime1 (get), for instance), the stepsize is measured in the time standard the user specifies even though the comparisons and propagation for SGP4 occurs in TAI. If the length of the time steps are important, this may be a necessary calculation. However, the performance of the SGP4 propagation can be improved by specifying the input values in TAI. Apart from leap seconds, UTC and TAI have the same timescale so the stepsizes will result in the same times in either standard.