TimeScale

Time scale

Description:

This attribute identifies the time scale to which the time axis values of a TimeFrame refer, and may take any of the values listed in the " Time Scales" section (below).

The default TimeScale value depends on the current System value; if the current TimeFrame system is " Besselian epoch" the default is " TT" , otherwise it is " TAI" . Note, if the System attribute is set so that the TimeFrame represents Besselian Epoch, then an error will be reported if an attempt is made to set the TimeScale to anything other than TT.

Note, the supported time scales fall into two groups. The first group containing UT1, GMST, LAST and LMST define time in terms of the orientation of the earth. The second group (containing all the remaining time scales) define time in terms of an atomic process. Since the rate of rotation of the earth varies in an unpredictable way, conversion between two timescales in different groups relies on a value being supplied for the Dut1 attribute (defined by the parent Frame class). This attribute specifies the difference between the UT1 and UTC time scales, in seconds, and defaults to zero. See the documentation for the Dut1 attribute for further details.

Type:
String.

Applicability

TimeFrame
All TimeFrames have this attribute.

Time Scales

The TimeFrame class supports the following TimeScale values (all are case-insensitive):

An very informative description of these and other time scales is available at http://www.ucolick.org/ sla/leapsecs/timescales.html.

UTC Warnings

UTC should ideally be expressed using separate hours, minutes and seconds fields (or at least in seconds for a given date) if leap seconds are to be taken into account. Since the TimeFrame class represents each moment in time using a single floating point number (the axis value) there will be an ambiguity during a leap second. Thus an error of up to 1 second can result when using AST to convert a UTC time to another time scale if the time occurs within a leap second. Leap seconds occur at most twice a year, and are introduced to take account of variation in the rotation of the earth. The most recent leap second occurred on 1st January 1999. Although in the vast majority of cases leap second ambiguities won t matter, there are potential problems in on-line data acquisition systems and in critical applications involving taking the difference between two times.