|---------------------------------------------------------------|

|
|
|
|
|
MAXCLOCK 3.2 SPECIAL ASTRONOMICAL TOPICS
|
|
|
|
|
| ( Part 2 of the software documentation for MAXCLOCK 3.2 ) |
|
Copyright (c) 2010 Udo Mark
|
|
|
|
|
|
|
|
Table of Contents:
|
|
|
|
1. TIME-RELATED TOPICS
|
|
2. COORDINATE-RELATED TOPICS
|
|
3. LITERATURE REFERENCE
|
|
|
|
|
|---------------------------------------------------------------|

--- 1. TIME-RELATED TOPICS ------------------------------------INPUT VALUES:

Regarding input values, the program assumes that:
1) time values are strictly tied to Coordinated Universal Time
UTC, given in cardinal numbers, on a 24-hour scale;
2) time values are apart from UTC by a constant shift factor
only, e.g. according to a geographical zone time;
3) any date after and including Oct.15, 1582 conforms to
Gregorian calendar;
4) any date up to and including Oct.4, 1582 conforms to Julian,
resp. Julian proleptic calendar; (program does not support
Gregorian proleptic calendar)
5) the days 5th to 14th of Oct. 1582 do not exist;
6) since, in our calendar, any date is given in ordinal numbers,
no "zeroth" year can exist; (Same with month and day.)
7) to discriminate AD and BC, the years before Christ (BC) must
be preceded by a (only symbolic) minus sign. (1 BC to be given
as -1, 2 BC to be given as -2, etc.)
Do not confuse this with Cassini's notation, which assigns
cardinal numbers and thus mandates that the beginning of 1 BC
is expressed as 0.0, 2 BC as -1.0, etc.!)
8) years are within the range -9999 (which is 9999 BC) to +9999
(which is AD 9999);
If any input does not conform to these rules, an appropriate error
message will be issued.

JULIAN DATE:

Julian date is displayed both in terms of universal time JD(UT1)

and in terms of ephemeris time JD(ET).
JD(UT1) is derived from the calendar date at Greenwich and the
instantaneous value of UT1, for JD(ET) the quantity TT-UT1 is
added. (Regarding the modelling of TT-UT1 see below in section 2.)
The computation follows an algorithm given in [2], which uses the
conventional rules:
1) Gregorian calendar:
All exactly-400-divisible centennial years after AD 1582 are
treated as leap years. The upcoming idea, that AD 4000 and
AD 8000 may become ordinary years, is not implemented, these
years are also treated as leap years.
2) Julian calendar:
According to general usage, Julian calendar is implemented by
extrapolating emperor Augustus' modifications of the lengths of
the months back in time, and by disregarding the intercalation
errors made by the Romans before 8 BC.
Maximum error for JD(UT1) will be the DUT1 specification
inaccuracy given by the user, since UT1 is internally generated by
adding DUT1 and UTC.
Maximum error for JD(ET) is influenced by ephemeris time modelling
procedures. (See below in the section 2 about ephemeris time.)

MODIFIED JULIAN DATE MJD:

MJD uses the most widespread definition, which may be found in [5]
and [6]. This is: MJD = JD - 2400000.5

DAY OF THE WEEK:

Being fully aware that the 7-day-rhythm is a relatively young
invention in time reckoning, it has been extrapolated over the
whole range of input dates just for simplicity.

UTC, UT1, and DUT1:

Since software version 3.0 the UT1 timescale is generated as
follows:
a) If you operate the program in the "clock mode", the DUT1 value
from the configuration file is used and added to UTC to
generate UT1.
b) In the non-clock-mode, it is mandatory to supply the
respective DUT1 values through input file, resp. through
keyboard. These values will be used throughout and will
override the DUT1 setting in the configuration file.
c) The sign convention is: DUT1 = UT1 - UTC
(Former software versions used DUT1 = UTC - UT1)
Through this procedure, UT1 is computed individually and exactly,
both in clock- and non-clock mode.
With respect to upcoming ideas suggestimg that DUT1 bounds should
be extended beyond the established 0.9 seconds, the program will

accept DUT1 values in the range +99...-99 seconds.

Regarding sources of historical DUT1 values as well as future
predictions, see below in chapter "A FEW FURTHER REMARKS ON TIME
ACCURACY".

EPHEMERIS TIME:
See below in section 2.

MEAN SOLAR TIMES:

As mentioned, Greenwich Mean Solar Time (UT1) is computed as
UTC+DUT1.
Thus, the maximum error for Greenwich mean solar time will be:
# only the DUT1 specification inaccuracy in the
configuration file.
Maximum error for local mean solar time will be:
# the DUT1 specification inaccuracy in the configuration
file,
# plus the overall longitude specification inaccuracy in the
configuration file.

EQUATION OF TIME:
As general convention directs, the equation of time is always
based on the apparent coordinates of the Sun (including nutation
and aberration, referred to true dynamical ecliptic and equinox of
date), without regard to any specifications in the configuration
file. As usual, the the sign convention is:
EquationOfTime = ApparentSolarTime - MeanSolarTime
Instead of approximations and iterative procedures used in former
software versions, since version 3.0 the hour angle of apparent
true Sun referred to true equator of date is computed for any
instantaneous moment of time and used for finding equation of
time.
According to the 0.006 arcsec longitude error for the Sun, the
maximum overall error will no more exceed 0.4 milliseconds of
time. (for years -4000...+8000)

APPARENT SOLAR TIMES:

These are calculated from the respective mean solar times by
adding the equation of time.
Thus, error for Greenwich apparent solar time will be combined
from the errors of these two components, yielding a maximum error
of about:
# the DUT1 specification inaccuracy in the
configuration/input file,
# plus 0.4 milliseconds.(for years -4000...+8000)

Error for local apparent solar time will be:

# The DUT1 specification inaccuracy in the
configuration/input file,
# plus 0.4 milliseconds,
# plus the overall longitude specification inaccuracy in the
configuration file.(for years -4000...+8000)

MEAN SIDEREAL TIMES:

Computation follows the generally acknowledged equation (IAU 1982
model,[17]) relating Greenwich mean sidereal time and universal
time for 00:00 UT1 of every day. Identical versions of this
equation can be found in [1], [3], [4], [5], and [6].
Greenwich mean sidereal time will be in error by:
# any intrinsic inaccuracy of this equation,
# plus the DUT1 specification inaccuracy in the
configuration file.
Local mean sidereal time will be in error by:
# any intrinsic inaccuracy of this equation,
# plus the DUT1 specification inaccuracy in the
configuration file,
# plus the overall longitude specification inaccuracy in the
configuration file.

EQUATION OF EQUINOXES (EQEQ) and APPARENT SIDEREAL TIMES

Display of these items is a new feature since software
version 3.0.
The computation of nutation and EQEQ generally follows the
conventinal paradigm, given by the IAU resolutions of the last
decades. (The new paradigm described by the IAU 2000 resolution
will probably be realized in a future software version.)
* In general, the full IAU 1980 lunisolar nutation series as
given in [6] is used, of which the smallest coefficients are
appr. 0.1 milliarcsec longitude, equivalent to EQEQ variations
of 6.1 microseconds.
* Additionally, Herring's lunisolar corrections as of 1987
[6,11] may be included, which give corrections up to
7.25 milliarcsec longitude (443 microseconds in EQEQ).
* Further, Vondrak's full planetary correction series [6,12,13]
may be included, which gives corrections up to 0.20 milliarcsec
longitude (12.2 microseconds in EQEQ).
* Two procedures may be selected: The classical expression,
using the cosine of the true obliquity or the more
recent IAU 1994 equation, using the cosine of the mean
obliquity together with terms for the longitude of the
ascending node of the Moon [5], [18]. Discrepancy between these
procedures may be up to 200 microseconds. For the latter
equation, the expression for the ascending node of the Moon as
given in [6], pp.114 is used.
* Regarding the modelling of the obliquity of the ecliptic, see
below in the section "COORDINATES IN GENERAL AND OBLIQUITY
MODELLING".
Apparent sidereal time is found by adding EQEQ and mean sidereal

time.
Its error is equivalent to the error of mean sidereal time (see
above), plus the uncertainties of EQEQ.

A FEW FURTHER REMARKS ON TIME ACCURACY:

To maintain reasonable accuracy for the display of your local
times, you should specify your local geographic longitude in the
configuration file with an appropriate tolerance:
For example, a tolerance of 0.004 degree (15 arcsecs, which is
appr. 464 meters near the equator, resp. 327 meters at 45 degrees
latitude) will introduce an error of one second of time.
Specification of geographic longitude with arcsec-accuracy should
easily be possible with a survey map of your location, preferably
of 1:25000 scale, or with a GPS receiver.
To achieve an even higher accuracy (below 1 second), consider the
following aspects:
1.) Geographical coordinates:
For astronomical computations, the mandatory frame is the
BIH/ITRF frame, which is almost identical with the WGS-84
geodetic reference frame.
Using a GPS receiver, you will automatically receive geographic
longitude in this WGS-84 reference frame (unless you explicitly
programmed another geodetic datum into the receiver).
On the other hand, when using conventional maps, longitudes are
given in terms of local geodetic datum and must be transformed
to WGS-84 reference frame first. This transformation gives
corrections of a few arcsecs and can be done with lenghthy
procedures only ( e.g. Molodensky equations, Helmert
transformation, or multiple regression equations).
Appropriate equations and parameters may be provided through
your local survey authorities, mapping agencies, or university
geodetic departments.
Commercial and free software is also available to do this, and
most GPS receivers are capable to transform stored waypoints
from one geodetic datum to another.
2.) Deflection of the Vertical:
The longitude part of the "deflection of the vertical" will
also introduce an error as long as you specify pure geographic
(geodetic) instead of astronomical longitude. Deflection may
amount to 30 arcsecs in the (seldom) case of severe gravity
anomalies.
Thus, for maximum precision, you should specify true astronomical
longitude instead of geographic/geodetic longitude.
Deflection values may also be obtained through your local
survey authorities, mapping agencies, or university geodetic
departments.
(Note that the coarse method of investigating the slope of
WGS-84 geoid height data values may not yield necessary smallscale accuracy.)
3.) DUT1:
When striving for such level of precision, it is required to
supply the precise instantaneous value of DUT1.
Any inaccuracy in DUT1 will affect all solar and sidereal time
figures in the same way, since all these are ultimately derived
from UTC.
Besides, 1/10 second DUT1 inaccuracy, for example, is

equivalent to 1.5 arcsec longitude inaccuracy.

DUT1 values are communicated by national timekeeping
authorities. Values for past and present may also be obtained
through the documents of the National Earth Orientation Service
at US Naval Observatory [7a], from the documents of the IERS
EOP Product Center at Paris Observatory [7b], or from the
Bulletins of the IERS, available both at Paris Observatory and
at US Naval Observatory.

TIME LAG OF THE DISPLAY:

Even if your computer clock and operating system are right on
time, there is always a small time lag between clock time and the
moment when the time telegram appears on the screen. (Computations
cannot be done in zero time.)
The lag is usually not important, but may be up to several seconds
on older and slower computers without a math coprocessor.
The lag is shown in milliseconds in the upper right corner of the
screen display. You may perceive it, when comparing the ticks of a
time signal receiver against the update rhythm of the screen. This
lag, of course, does in no way affect the numerical results in the
display.

--- 2. COORDINATE-RELATED TOPICS ------------------------------------------EPHEMERIS TIME - THE INTERNAL EPHEMERIS TIME MODEL:
For all position computations of the Sun and Moon, terrestrial
time TT is used. This is the equivalent of former ephemeris time
ET, resp. of former terrestrial dynamic time TDT.
Delta-T, which is the instantaneous value of TT-UT1, is found
through a set of state-of-the-art procedures, such as empirical
approximations (for ancient ages), tabulated data (for the last
four centuries), and extrapolation. This is called the internal
ephemeris time model.
Its result is shown on the screen as "DT", accompanied by a
display of JD(ET).
Since software version 3.0, the computation has been thoroughly
modified. In general, it follows the model outlined by Stephenson
and Morrison [14], adjusted for a value of
25.7376 arcsec/century^2 for the tidal acceleration of the Moon.
This value had been deducted from the adjustment of the ELP2000-82
to observations [13]. The equations derived from this value may be
found both at Chapront [13] and at Meeus [4].
The details of this internal ephemeris time model are as follows:
* For dates before 948, Chapront's equation 26 is used (with a
very minor correction to enable a smooth transition to the next
time interval). The equation is:
DT = 2176.8005 + 497t + 44.1t^2
* For 948 to 1600, Chapront's equation 25 is used.
It is: DT = 102 + 102t + 25.3t^2

* For 1600 to 1630, values have been generated by a spline

function, which smoothly joins Chapront's equation 25 to
Stephenson/Morrison's "table 3" values (corrected for new tidal
acceleration, so that in 1630 we have 82.5 seconds).
* For 1630 to 1955, Stephenson/Morrison's "table 3" values
(corrected for new tidal acceleration) are used.
* For 1955 to 2001, Stephenson/Morrison's "table 3" values from
[14] (uncorrected, since they come from atomic clock
measurements) together with latest values given by US Naval
Observatory on their webpage [7] are used. (These equal the
values in the Astronomical Almanac [5].)
* Starting with 2002, values have been computed according to
DT=32.184 + (TAI-UTC) - (UT1-UTC)
where (UT1-UTC) has been taken from the smoothed combined IERS
C04 series EOP-C04 (including solid Earth zonal tides) [7b].
* For Jan.2010 to 2100, values have been generated by a spline
function, which smoothly joins latest such computed value with
Chapront's equation 25.
* From 2100 onwards (where DT=229.3 s), again Chapront's
equation 25 is used.
(Former software versions up to 2.2 used a constant DT value
after year 2001 instead of these procedures.)
The following table gives a very rough outline of the values
generated in this way (the program of course generates with full
accuracy):
Year
9999
4713
753
1
1600
1900
1950
2000
2100
9999

BC
BC
BC
AD
AD
AD
AD
AD
AD
AD

appr.DT
160 hours
46 hours
6 hours
3 hours
98 seconds
-3 seconds
29 seconds
64 seconds
230 seconds
47 hours

(The values generated for ancient times and extreme future should
of course be seen as a computational outcome only, not being
authoritative in any way.)
As research continued in the last decades, procedures and
numerical values have been subject to continueing refinement, but
yet leave room for considerable uncertainties.
Therefore, if you intend to compare the coordinates of Sun and
Moon found by MAXCLOCK against such coordinates found by other
software, have a very careful look at the modelling of DT.
If the DT modelled by other software will deviate from MAXCLOCKadopted values, coordinates of Sun and Moon will also deviate.
The same is the case if real-world DT deviated from the DT model
adopted by MAXCLOCK. Then, the coordinates found by MAXCLOCK would
differ from reality.
The magnitude of this effect is as follows:
Deviation in
DT-model, or
deviation versus

Longitude
discrepancy
for

Longitude
discrepancy
for

real-world DT

Moon

10
20
50
.1
.2
.5
1
2
5
10
30
1
2
5
10
30
1
2
5
10

5.48
11.0
27.4
54.8
110
274
548
1.10
2.75
5.48
16.5
32.9
1.09
2.75
5.49
16.5
32.9
1.10
2.74
5.48

msec
msec
msec
sec
sec
sec
sec
sec
sec
sec
sec
min
min
min
min
min
hour
hours
hours
hours

Sun
mas
mas
mas
mas
mas
mas
mas
arcsec
arcsec
arcsec
arcsec
arcsec
arcmin
arcmin
arcmin
arcmin
arcmin
degree
degree
degree

.416
.832
2.08
4.16
8.32
20.8
41.6
83.2
208
416
1.25
2.50
5.00
12.5
12.0
1.25
2.50
5.00
12.5
25.0

mas
mas
mas
mas
mas
mas
mas
mas
mas
mas
arcsec
arcsec
arcsec
arcsec
arcsec
arcmin
arcmin
arcmin
arcmin
arcmin

EPHEMERIS TIME - USER-SUPPLIED DT:

Since software version 3.0 one may override the internal ephemeris
time model with user-specific values of DT.
The overriding works both in clock and non-clock mode and is
initiated by an appropriate setting in the configuration file
("dt" in line eight), and then supplying a value either in
configuration file line nine (clock mode) or through inputfile or
keyboard (non-clock mode).
Values may range from appr. -999 to +999 hours.
Note that in this case screen display will change from "DT" to
lowercase "dt" to indicate that user-supplied value has been used
and internal model has been overridden.

COORDINATES OF THE SUN:

According to the specifications in the configuration file,
coordinates may be computed without nutation and aberration (pure
geometric), with nutation alone, with aberration alone, or with
both effects being taken into consideration, thus yielding full
apparent coordinates.
They may be referenced to mean dynamical ecliptic and equinox of
date or to FK5 catalog equinox.
Since software version 3.0, the other Sun-related phenomena such
as constellation, zodiac sign, equinox/solstice annnouncements,
and equation of time are _always_ calculated _with_ nutation and
aberration (apparent), and are _not_ influenced by the
nutation/aberration specifications in the configuration file.
Therefore, if you wish the Sun numerical coordinates to strictly
agree with the other Sun-related phenomena, have the coordinate
specifications set to "N" and "A" in the configuration file (which
is also the preset default).

Since software version 3.0 an even more accurate algorithm has

been used, namely the full VSOP87, as given by Bretagnon and
Francou [8].
The transformation from VSOP87 ecliptical coordinates into FK5 is
computed according to Meeus [4], pp.219.
With VSOP87, accuracy in ecliptical longitude has been increased
from the former 3.0 arcsecs to 0.006 arcsecs, at least for the
time range from year -4000 to +8000.
Accordingly, error for right ascension will amount to appr.
0.4 milliseconds.
Error for declination will be influenced by obliquity modelling,
see below.
Error for the Earth-Sun distance is appr. 3.E-8 astronomical
units.
According to the 0.006 arcsec longitude error, the time instants
for equinoxes and solstices, as well as the time instants when the
Sun crosses zodiac sign boundaries will be uncertain by appr.
0.15 seconds of time, and thus be well spotted to the nearest
second.
As for the constellation where the Sun is situated, the former
procedure has been replaced by a new solution:
The instantaneous coordinates of the apparent Sun are reduced for
precession to coordinates of epoch 1875 (when constellation
boundaries were defined to be lines of constant right ascension
and constant declination [15]).
This reduction is made with the rigorous precession equations of
the IAU 1976 precession model given in in [4] and [6].
The constellation is then found by interrogating a dataset derived
from the 1875 constellation dataset [16].
Since the precession model is known to have limited accuracy, the
following uncertainties can be expected for the constellation
boundaries crossover times:
time interval

precession model
Euler angle error

AD 1960
AD 1640
500 BC
1200 BC
4200 BC
6800 BC
9999 BC

<
<
<
<
<
<
>

AD 2040
AD 2360
3000 AD
3900 AD
5600 AD
8200 AD
9999 AD

0.1 arcsec
1 arcsec
3 arcsec
10 arcsec
100 arcsec
1000 arcsec
1000 arcsec

crossover uncertainty
(order of magnitude)
for Sun
< 2.4 seconds
< 24 seconds
< 1.2 minutes
< 4 minutes
< 40 minutes
< 6.7 hours
> 6.7 hours

Note that all position errors may be additionally aggravated by

the uncertainties related to the internal determination of TT,
especially for ancient and future ages (see chapter on ephemeris
time above), and by the error in the specification of DUT1.

COORDINATES OF THE MOON:

Entirely analogous to the Sun, the coordinates may be calculated
as "pure geometric", "nutation only", "aberration only", or "full

apparent", referenced to mean dynamical ecliptic and equinox of

date or to FK5 catalog equinox, according to the specifications in
the configuration file.
Aberration is modelled as given in [9].
Since software version 3.0, the other Moon-related phenomena such
as phase, illumination, zodiac sign, constellation, elongation,
and phase announcements are _always_ calculated _with_ nutation
and aberration (apparent), and are _not_ influenced by the
nutation/aberration specifications in the configuration file.
Therefore, if you wish the Moon numerical coordinates to strictly
agree with the other Moon-related phenomena, have the coordinate
specifications set to "N" and "A" in the configuration file (which
is also the preset default).
Since software version 3.0 an even more accurate algorithm has
been used, namely the ELP2000-82B, as given by Chapront and
Chapront-Touze [10]. The transformation from ELP2000-82B
ecliptical coordinates into FK5 is computed according to Meeus
[4], pp.219.
For computational speed and in order to have a temporal spotting
capability comparable to that of Sun-related phenomena, the
coefficient data for ELP2000-82B have been truncated in such a way
as to give 0.05 arcsec longitude accuracy for the timespan of
120 centuries on both sides of year 2000.
Same accuracy holds for latitude, and distance is evaluated to
3.E-8 of nominal distance.
Accordingly, error for right ascension will amount to appr.
3.3 milliseconds.
Error for declination will be influenced by obliquity modelling,
see below.
(For comparison: Before software version 3.0, errors were
10 arcsecs for longitude, 3 arcecs for latitude, and 5.5E-5 of
nominal distance.)
According to the 0.05 arcsec longitude error, the time instants
for the Moon crossing zodiac sign boundaries will be in error of
appr. 0.1 seconds, the uncertainty of the time instants of Moon
phases will be in the same order of magnitude and thus phases may
be well spotted to the nearest second.
(For comparison: Before software version 3.0, time uncertainty was
well beyond one minute.)
As for the phase, it is simply computed from the difference in
ecliptical longitude compared with the Sun. Thus, phase will take
values of exact 180 degrees and exact zero on new and full Moon,
respectively, whereas rigorous phase usually does not.
Elongation is computed exactly and therefore will practically
never reach zero.
Illuminated fraction is derived from exact selenocentric
elongation of the Earth from the Sun and therefore will not amount
to 100 percent on ordinary full Moon and not reach exact zero on
ordinary new Moon.
Range is given as fraction of mean range, which has been assumed
as 384400 kilometers exactly.
Constellation display for the Moon is new since software
version 3.0 and is found as with the Sun, see above.
The crossover uncertainties are as follows:

time interval

precession model
Euler angle error

AD 1960
AD 1640
500 BC
1200 BC
4200 BC
6800 BC
9999 BC

<
<
<
<
<
<
>

AD 2040
AD 2360
3000 AD
3900 AD
5600 AD
8200 AD
9999 AD

0.1 arcsec
1 arcsec
3 arcsec
10 arcsec
100 arcsec
1000 arcsec
1000 arcsec

crossover uncertainty
(order of magnitude)
for Moon
< 0.18 seconds
< 1.8 seconds
< 5.5 seconds
< 18 seconds
< 3 minutes
< 30 minutes
> 30 minutes

Note that, as with the Sun, all position errors may be

additionally aggravated by the uncertainties related to the
internal determination of TT, especially for ancient and future
ages (see chapter on ephemeris time above), and by the error in
the specification of DUT1.

COORDINATES IN GENERAL AND OBLIQUITY MODELLING:

All coordinates are geocentric and thus do not allow for parallax
or refraction. Consequently, this software should _not_ be used to
track eclipses by comparing the coordinates of Moon and Sun.
(Algorithms for doing this may be found, for example, in [2].)
If you are particular about parallax/refraction, you may of course
consider the usual corrections. For the Sun, parallax correction
may amount to 8.8 arcsecs, for the Moon parallax may amount to one
degree, and refraction may amount to 0.5 degree near horizon.
Right ascensions and declinations are computed from ecliptical
coordinates.
Regarding the variability of the obliquity of the ecliptic, it is
necessary to have an expression yielding reasonable obliquity
values for the whole range of input years from 9999 BC up to
AD 9999.
Starting with software version 3.1, the user can select between
the usual third-order polynomial of the IAU 1980 model and
Laskar's tenth-order 1986 polynomial (as given in [3] and [4]).
As reference value for epoch 2000, both polynomials use the
IAU 1976 value 23 deg 26 min 21.448 arcsec.
(The former software version 3.0 did use the IERS 1992 value
23 deg 26 arcmin 21.4119 arcsec. This proved to be not
satisfactory.)
The estimated errors of the obliquity polynomials (as cited in
[4]) are as follows:
IAU third-order:

1 arcsec over a period of 2000 years,

10 arcsec over a period of 4000 years

Laskar 10th order: 0.01 arcsec over a period of 1000 years,

a few arcsecs after 10000 years
The discrepancy between the two polynomials is as follows:
year

obliquity
discrepancy

-10000
-2000

+160 arcsec
-10 arcsec

+1
-1.4 arcsec
+1000
-0.2 arcsec
+1900
-0.0054 arcsec
+2000
0
+2010 +0.00057 arcsec
+2100
+0.0063 arcsec
+3000
+0.28 arcsec
+4000
+1.6 arcsec
+10000
-7.1 arcsec

--- 3. LITERATURE REFERENCE -------------------------------------[1] Dennis D. Mc Carthy:

"ASTRONOMICAL TIME", in "Proc. of the IEEE", volume 29, no. 7,
(July 1991), pp.915 ff.
(This IEEE magazine contains a variety of other instructive
articles about timekeeping.)
[2] Peter Duffett-Smith:
"ASTRONOMY WITH YOUR PERSONAL COMPUTER", second edition (1990),
259 pages, by Cambridge University Press, Cambridge CB21RP,
United Kingdom.
(Supplies a lot of medium-precision algorithms for
celestial mechanics, in BASIC language.)
[3] Jean Meeus:
"ASTRONOMISCHE ALGORITHMEN", first German translation (1992),
460 pages, by J.A.Barth Verlag, Leipzig / Berlin / Heidelberg.
(Supplies recipes similar to [2], but with more
explanations on algorithms, yet higher precision, and wider
range of topics. Includes a separate chapter on numerical
mathematics and machine arithmetic pitfalls, as well as
numerous literature references. Because of many printing
errors in the both German translations, it is recommended
to refer to the most recent English original instead (see
below).
[4] Jean Meeus:
"ASTRONOMICAL ALGORITHMS", second english ed.(1998),
477 pages, by Willman-Bell, Richmond VA, USA.
[5] US Naval Observatory and Royal Greenwich Observatory:
"THE ASTRONOMICAL ALMANAC FOR THE YEAR 2001", by US
Government Printing Office at Washington DC 20402, USA, and by
Her Majesty's Stationery Office at London SW85DT, UK.
[6] US Naval Observatory (edited by P. Kenneth Seidelman):
"EXPLANATORY SUPPLEMENT TO THE ASTRONOMICAL ALAMANAC", (1992),
by University Science Books, Sausalito, CA 94965, USA
[7] US Naval Observatory:
URL=ftp:/maia.usno.navy.mil/ser7/deltat.data
[7a] US Naval Observatory:
URL=http://www.usno.navy.mil/USNO/earth-orientation

[7b] EOP Product Center of the International Earth Rotation

Service at Paris Observatory:
URL=http://hpiers.obspm.fr/eop-pc
[8] P. Bretagnon, G. Francou:
"PLANETARY THEORIES IN RECTANGULAR AND SPHERICAL VARIABLES:
VSOP87 SOLUTION", in Astron. Astrophys. 202, 309 (1988);
and
"THEORIE DU MOUVEMENT DE L'ENSEMBLE DES PLANETES (VSOP82)", in
Astron. Astrophys. 114, 278 (1982);
Description, data files, and algorithm examples also via
Internet at Paris Observatory:
URL=ftp://ftp.imcce.fr/pub/ephem/planets/vsop87/
(as of Jan.2001)
[9] J. Chapront and M. Chapront-Touze:
"LUNAR TABLES AND PROGRAMS FROM 4000 B.C. TO A.D. 8000", first
ed. (1991), 164 pages, by Willman-Bell, Richmond VA, USA.
[10] J. Chapront and M. Chapront-Touze:
"ELP 2000-85: A SEMI-ANALYTICAL LUNAR EPHEMERIS ADEQUATE FOR
HISTORICAL TIMES", in Astron. Astrophys. 190, 342 (1988);
and
"THE LUNAR EPHEMERIS ELP 2000", in Astron.Astrophys. 124, 50
(1983);
Description, data files, and algorithm examples also via
Internet at Paris Observatory:
URL=ftp://ftp.imcce.fr/pub/ephem/moon/elp82b/
(as of Jan.2001)
[11] T. A. Herring:
"HERRINGS CORRECTION TO THE IAU 1980 NUTATION SERIES", BIH
Annual report for 1987, no. D-106, (1987)
[12] J. Vondrak:
"ON THE INDIRECT INFLUENCE OF THE PLANETS ON NUTATION - I.
Effects of Planetary Perturbations in Lunar Orbit",
in Bull. Astron. Inst. Czechosl. 34, 184, (1983)
and:
"II. Effects of Planetary Perturbations of the Earth's Orbit",
in Bull. Astron. Inst. Czechosl. 34, 311, (1983)
[13] J. Chapront, M. Chapront-Touze, G. Francou:
"NOUVELLES EXPRESSIONS DES TERMES SECULAIRES DANS LUNAR TABLES
AND PROGRAMS FROM 4000 BC TO AD 8000", note scientifique no.
S055 of the Bureau des Longitudes, Paris, (Dec.1997)
[14] F. R. Stephenson and L.V. Morrison:
"LONG-TERM CHANGES IN THE ROTATION OF THE EARTH: 700 BC TO AD
1980", in Phil. Trans. R. Soc. Lond. A313, 47-70 (1984)
[15] E. Delporte:
"DELIMITATION SCIENTIFIQUE DES CONSTELLATIONES", Cambridge
University Press, 1930
[16] A.C. Davenhall and S.K. Leggett:
"A CATALOGUE OF CONSTELLATION BOUNDARY DATA", 1990, catalog
no. 6042C from the International Network of Astronomical Data
Centers, downloadable from:

URL=http://cdsweb.u-strasbg.fr/viz-bin/Cat?VI/49
[17] IAU:
Transactions of the International Astronomical Union, XVIII B,
67 (1983).
[18] IAU:
Resolution C7, Recommendation 3 (1994)

End of MAXCLOCK 3.2 SPECIAL ASTRONOMICAL TOPICS -----------------