Time and Time Standards
As mentioned in the discussion of Units, the second is the fundamental unit of measure used to express quantities of time. The definition of a second, however, depends upon the particular time standard being used. Various time standards exist in order to account for the apparent passage of time based on the Earth's rotation with respect to the Sun, to account for relativistic effects on the passage of time observed in different reference frames, and to provide a source in an identified reference frame against which other time standards can be measured.
The time standards supported in Components are listed in the following table. All of these time standards are accessible via static properties on the TimeStandard class.
Universal Time 1
Earth rotational time
Coordinated Universal Time
Global Positioning System Time
International Atomic Time
Barycentric Dynamical Time
relativistic dynamical time
You can extend STK Components 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, STK Components 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. Components 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. Components 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 STK Components, 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, STK Components 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 STK Components. 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 STK Components.
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.