Sentinel-3 Time Stamp vs. Acquisition Period

I have found an offset between the startTime and stopTime in the acquisitionPeriod product metadata and the first and last time_stamp of the product in the time_coordinates of around 1 min 7 sec.

Is there a reason for this?

I’m not aware of any reason for this. I’ll try to get some information.

As an example product: S3A_OL_1_EFR____20161023T100950_20161023T101250_20161023T120602_0179_010_122_1979_SVL_O_NR_002.SEN3

In the metadata:
acquistionPeriod.startTime - 2016-10-23T10:09:50.693521Z
acquisitionPeriod.stopTime - 2016-10-23T10:12:50.693521Z

time_stamp.value.1 - 530532607696570
time_stamp.value.4091 - 530532787661577

Converting these microseconds since 1/1/2000 to datetime objects in python as:
date = dt(2000, 1, 1, 0, 0 ,0) + timedelta(seconds=time_stamp/1e6)

Find:
time_stamp.value.1 -2016-10-23T10:10:07.696570
time_stamp.value.4091 - 2016-10-23T10:13:07.661577

1 Like

Additionally the metadata claims duplicated pixels are 0%

Hi Sam,

actually the difference you observed is only 17 seconds, not 1 min and 7 second.
However, the difference comes from the different time bases. Start and stop are in UTC and the time_stamps are in GPS time as recorded on the platform (I think).
Below is the explanation of the difference I have received.

GPS time is an atomic-clock based time counter, giving very accurate elapsed time since a given reference date. Another of this kind is TAI (Temps International Atomique or International Atomic Time), working the same but with a different reference. Then comes UTC (Universal Time Coordinated), an Earth based time reference, that has to be corrected from the above (that can be considered as Galilean, to make a parallel with space references) to account for Earth rotation actual angular speed, including irregularities, so that (roughly) you face the Sun at noon and you get back to the same place after one year. Correction of UTC is made in the form of leap seconds, to be added or subtracted whenever need to get as close as possible to UT1 (accurate Earth rotation-based time) in order to stay within 0.9 seconds from UT1. Corrections are made at fixed dates, generally December 31 23:59:59, and exceptions 30 June same time (never occurred so far, to my knowledge). To make it short, TAI and GPS are absolute times, UTC and UT1 are “local ones” based on our way to refer to time based on relative position wrt Sun (noon and solstices/equinoxes). In addition to leap seconds, this is also the reason for leap years (those with 29 days in February) and the complexity of the leap years law: every 4 years but centuries but multiples of 400 years but millenaries etc…
The current GPS/UTC difference is 18 seconds, it was 17 before last New Year Eve. GPS is ahead of UTC.

This means the difference is expected.

Regarding the duplicated pixels, it seem there was an issue in the processing software.
Your product has the version 3.23 and one from 2017-03-28 has the version 3.25 and there the value is correctly set.

2 Likes

Thanks Marco, really useful explanation