ESA Earth Home Missions Data Products Resources Applications
EO Data Access
How to Apply
How to Access
RA2/MWR Data Formats Products
Frequently Asked Questions
Main RA-2 Level 2 Algorithms (Non-Ocean)
Main MWR Level 1b algorithms
Main RA-2 Level 1b algorithms
MWR Instrument
RA-2 Instrument
RA-2 and MWR Instruments
MWR Instrument Characteristics and Performance
In-flight performance verification
MWR Instrument Description
RA-2 Instrument Characteristics and Performance
In-flight Performance verification
RA2/MWR Products and Algorithms
RA-2/MWR Auxiliary files
Common Auxiliary Data Sets
Level 2 processing
Level 1b processing
Specific Topics Related To The Radar Altimeter
Orbit interpolation
Measurement Reference
Time Handling And Leap Seconds
RA-2/MWR Level 2 Products And Algorithms
RA2/MWR Level 2 Products
Averaged Ku chirp band
Ocean depth/land elevation
RA-2 ionospheric correction
RA-2/MWR Level 1b Products and Algorithms
RA-2/MWR Level 1b product
MWR Level 1b algorithms
Level 0 products
MWR Level 0 products
Products Evolution History
Definitions and Conventions
Organisation of Products
Data Handling Cookbook
Characterisation And Calibration
Latency, Throughput And Data Volume.
Product size
RA2/MWR Products User Guide
Further reading
How to use RA-2/MWR data
How To Choose RA-2/MWR Data Products
Summary of Applications vs. Products
Peculiarities of MWR
Peculiarities of RA2
Geophysical Coverage
Principles Of Measurement
Scientific Background
ENVISAT RA2/MWR Product Handbook
Site Map
Frequently asked questions
Terms of use
Contact us


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 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 this point.

There are several time references used in the EnviSat context:

  • 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. 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:

state_vector_time < 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 restituted file.

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 fulfilled is:

utc_sbt_time = utc_sbt_time + leap_sign

while in case of (2) is:

utc_sbt_time = utc_sbt_time - leap_sign

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 product model
  • 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. 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 correction. Figure2.4 and Figure2.5 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 the geolocation.

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. Leap_sign

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 day after).

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. Leap_err

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 <= state_vector_time ))

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).


Keywords: ESA European Space Agency - Agence spatiale europeenne, observation de la terre, earth observation, satellite remote sensing, teledetection, geophysique, altimetrie, radar, chimique atmospherique, geophysics, altimetry, radar, atmospheric chemistry