2.8.2 Time Handling And Leap Seconds
Time Handling is described in :
"Time and Orbit State
Vector handling within the PDS
processing chain." Guidelines
PO-TN-ESA-GS-00554 Iss. 1.3
126.96.36.199 Leap Second Description
There are three fields, leap_utc, leap_sign
and leap_err that relate to the
leap second usage. They are contained in the
MPH (fields 31, 32 and 33).
Before analysing in detail each of these
fields a description of the leap
second origin can be useful at
There are several time references used in the
- TAI: a very stable
atomic time scale found
only in DORIS products, and not
used in PDS processing.
- UT1: time of the Earth
clock, which performs
one revolution in about 24h.
It's used as time
reference for all orbit state vectors
and it's necessary
for pointing at celestial targets.
- UTC : time scale used
as reference for all
products datations. This time is
an approximation of UT1,
but for pointing at terrestrial
targets from the satellite, it provides
enough accuracy, due to
the short distance between the satellite
and the Earth.
188.8.131.52 Leap second correction
The occurrence of a leap
second may introduce a
discontinuity in the UTC time line used
during the processing, and has to be corrected.
This discontinuity is
introduced when one of the
following conditions is fulfilled:
leap_utc < utc_sbt_time (1)
utc_sbt_time < leap_utc
< state_vector_time (2)
where state_vector_time is
the UTC time of the Orbit State
Vector (field 17 in the MPH) and
utc_sbt_time, or UTC reference time, is the
utc time corresponding to the
satellite binary time (field 27 in
the MPH). The Orbit State Vector time
corresponds to the time of the
Ascending Node crossing if the OSV
information is generated from a
predicted file. The OSV time is
equal or just after the sensing start time
of the product being processed,
if the OSV is generated from a
The important point here is
that there is no warranty that
the state_vector_time and the utc_sbt_time
will coincide. Hence, conditions (1) or (2)
are likely to be satisfied.
The key point to remember is
that all information provided by
the PF_HS related to the UTC
time that occurs after the leap_utc has been
corrected for the leap second.
That's why there will exist a
discontinuity between the UTC reference time
(utc_sbt_time) and the OSV time
(orbit_state_vector) in case eqs. (1) or
(2) are fulfilled, since one of the
times will be already corrected
for the leap second while the other not.
The L1b processing must
remove this discontinuity in the
UTC time line by adjusting the UTC
reference time before using it for the processing.
The correction to be
performed in case (1) is
utc_sbt_time = utc_sbt_time
while in case of (2) is:
utc_sbt_time = utc_sbt_time
The leap second correction
will ensure that the results
obtained using the corrected utc_sbt_time
are time continuous with respect to the OSV time.
The corrected utc_sbt_time
is not to be written to the
output MPH. The correction is only done
internally to the L1b processing.
Note that the leap
information (i.e. leap_utc,
leap_sign and state_vector_time)
necessary to perform the leap
correction is extracted:
for the IPF: from the
for the ESLs reference
prototypes: from the
input product MPH (Level 0), or
from the OSV file MPH,
if a restituted orbit file is available.
Thus, the coherency between
the data used by both IPF and
ESLs processors is warrantied, since the
PF_HS will always include the best available
OSV information in the product model.
184.108.40.206 Evolution of L1b time stamps during a
leap second occurrence
As stated before, the leap
second will be introduced
(leap_utc), if necessary, at midnight of the
last day of December or June.
Let's call 'true
UTC time', the
time that follows the leap second jump,
and 'product UTC time'
the one used to tag the
processed records. We will see
below that the 'product UTC
time' will differ from
the 'true UTC time'.
If a leap second occurs, the
'true UTC time' line
will have a jump of one second at
leap_utc. That is; a second will be added,
if leap_sign = +1 (i.e. time
will pass from 23:59:59 to 23:59:60,
then to 00:00:00 and then to
00:00:01), or subtracted, if leap_sign
= -1 (i.e. time will pass directly from
23:59:59 to 00:00:01).
Instead, this jump will NOT
be reflected in the evolution of
the 'product UTC time' line.
This is because in the product,
the time is always continuous
with respect to the OSV time,
thanks to the leap second
show the evolution of the
'true UTC time' with
respect to the 'product UTC time'
in case of a positive and
negative leap second.
Hence, if there is a leap
second in the middle of a L0
product, this will be ignored by the
'product UTC time'. In other
words, the 'product UTC
time' will always be
continuous, regardless of the
leap second occurrence.
|Figure 2.4 evolution of the true and product UTC times, as a function of the elapsed time, if positive leap second
Once the time stamps of the
processed records have been
calculated, the CFI routines
(po_ppforb/po_interpol) will be called for
These routines produce time
continuous results with respect
to the time of the OSV time given
as input for the po_ppforb initialization
(i.e. the one contained in the
product MPH) or to the OSV time
obtained as output from the po_interpol initialization.
It means that the CFIs will
NOT introduce any leap second
correction. This is important, in
particular, for the po_interpol, since the
restituted orbit files used as
input are always corrected for leap
second (i.e. use 'true UTC time').
|Figure 2.5 evolution of the true and product UTC times, as a function of the elapsed time, if negative leap second
If the user wants to derive
the true UTC times corresponding
to the time stamps of a product (L1b
or L2), the leap_err flag in the MPH has to
be used. This flag, as it will
be explained later on, indicates if the
leap second correction has been performed or
not during the processing.
The leap_sign value
indicates whether the leap
second corresponds to an addition of one
second (leap_sign = +1) or a
subtraction of one second (leap_sign = -1).
The leap_sign, along with
the leap_utc, are provided
originally by the Bureau des Longitudes.
These values are then retrieved
by ESOC and put into the Variable
Header of the FOS orbit files. These
files are finally incorporated
into the PDS and the two leap fields copied
into the orbit files MPH.
The way the leap_sign is
set, by the PF_HS, is such that,
in case of leap second occurrence, it is
set to +1 or -1 in the products
corresponding to the three days
around the leap second (i.e. the day
before the leap second jump, the
day of the leap second jump, and the
The leap_sign value
appearing in the input L0 MPH
for the ESL reference processors, or in
the partially filled L1b MPH
(i.e. product model) for the IPF is
just copied into the higher output products
(i.e. L1b and L2 for the ESL
reference processors and L2 for the IPF).
That is; the leap_sign value
from the MPH shall not be
modified during the processing.
The leap second error flag,
set to 1 if a leap second has occurred
during the processing, and to 0 if not, is
to be determined by the ESL reference
processors/IPF according to the following algorithm:
if ((state_vector_time <=
leap_utc <= end time of the data set
to be processed ) or
(start time of the data set
to be processed <= leap_utc <=
then leap_err = 1
leap_err = 0
The start/end time of the
data set to be processed will coincide
with the sensing_start/sensing_stop
parameters from the input Level 0 MPH
(fields 10 and 11).