Additional Questions for Time Functions (Section 5.1)

[calvin.harman@…]

The value of UT1-UTC is required to calculate sidereal time. Getting this
difference requires the use of a table that is updated every few months. Within
this table, a formula is given to approximate the value of UT1-UTC. Can this
formula be used instead to avoid having to download a new table every few
months?

SLALIB provides a function for calculating to sidereal time (sla_GMST), but I
haven't found a function to calculate from sidereal time, which is required by
the psLSTToTime function in the SDRS. Is a such a function available?

Longitude is given as the second argument to the function psTimeToLST, but the
function sla_GMST does not take a longitude argument. The assumption is that
longitude is to be added to the result of the sla_GMST function. If so, is east
positive and west negative?

Is there an algorithm for the new function, psGetPoleCoords function? I don't
have a definition.

The functions psTimeToTM and psTMToTime were removed from the latest version of
the SDRS. Can they be added back in? Another function in psLib is currently
using these.

What's the difference between the functions psTAISub and psTAIDelta? They
appear to do the same thing.

[Paul Price]

I found the formula I think you're referring to at
​ftp://maia.usno.navy.mil/ser7/ser7.dat The blurb states: "The following
formulas will not reproduce the predictions given below, but may be used to
extend the predictions beyond the end of this table." Given this, I suggest the
following:

• If the current date is within the range of the table, interpolate from values

in the table (the changes are sufficiently small that linear interpolation
should be fine).

• If the current date is off the end of the range of the table, use the given

formula to extrapolate (and generate a warning).

• If the current date is off the front of the range of the table, then all bets

are off... Here, I think all we can hope do is extrapolate the table data.
I don't think that you should worry about the need to retrieve the data from the
web and parse the bulletin. Assume that it is available in a configuration file
on local disk; the format is something we should discuss.

Regarding the conversion to and from sidereal time, we just realised that we've
specified these incorrectly. The sidereal time should be a psF64, not a psTime
(since sidereal seconds aren't the same as regular seconds, and it's only
defined from 0 to 2pi). We have no need to convert sidereal time to UTC, so
psTimeFromLST is dropped. I updated the SDRS:

"To convert to Local Mean Sidereal Time, it is necessary to provide the
local longitude (specified in radians, positive East of Greenwich) as
well:
psF64 *psTimeToLST(psTime *time, psF64 longitude);"

Also, the conversion from UTC to LST is now specified in the ADD, so there's no
need to use SLALib's. The algorithm for psTimeGetPoleCoords is in the revised
ADD. I'll send you a copy tomorrow.

The psTimeToTM can stay as private functions, but I don't think the
implementation of the conversions to and from Ecliptic coordinates (which use
psTimeToTM) are correct --- they should not be using only the year, but the
month, day, hour etc as well. I suggest reworking these.

The difference between psTimeSub and psTimeDelta (renamed from old SDRS) is that
psTimeSub takes the difference between the two times, while psTimeDelta gives
the *absolute* difference. That is, the result from psTimeSub may be negative,
but the result from psTimeDelta will always be positive.

[robert.desonia@…]

The problem about conversions to and from Ecliptic coordinates is a separate
issue; a problem with PSLib implementation, not the specification
documentation.

I generated Bug #140 in the PSLib product to track it.

[calvin.harman@…]

I'm not sure about the extrapolation mentioned above for values off the front
of the table. Rather than extrapolation, shouldn't we use the same
approximation equation for values off the back of the table? If not, please
provide an algorithm or perferred means for extrapolation.

[Paul Price]

I don't think that the extrapolation function in Bulletin A is appropriate,
since it's not good even for the epoch that the table covers.

We don't expect that psLib will be used to extrapolate with high precision prior
to 1900, so don't bust a gut over this! Looking at a plot of the difference
between TDT and UTC over the years (back to 1620 or so!) reveals that the
behaviour was fairly constant (to within ~ 10 sec) between 1700 and 1900. I
suggest that prior to 1900, we simply assume that TDT = UTC.

[Paul Price]

Added the below to the ADD. In case you're interested, the full reference for
the citation is: Reingold & Dershowitz, Calendrical Calculations: The
Millenium Edition, Cambridge University Press, 2002.

Dates outside the ranges of the above tables shall generate a warning.
Dates later than those covered by the table shall be extrapolated
using the formula contained in the Bulletin A
(\code{​ftp://maia.usno.navy.mil/ser7/finals.all}); the formula shall
be easily configurable without recompiling (as the formula may change
with each Bulletin A). Dates prior to the those covered by the table
shall simply assume that TDT is identical to UTC (which, from Reingold
\& Dershowitz Figure 12.2 appears accurate to $\sim 10$ sec to about
1700). Archeoastronomy is not a perceived PSLib application, so there
is no need for high precision at such early dates.

[Paul Price]

Should be fixed in SDRS-07 and ADD-06 (7 September 2004).