Why are the sensing_start from the raw GOME-2 MPHR, and the value that is read with coda 2.22 different?

[tuinder]

Why are the sensing_start from the raw GOME-2 MPHR, and the value that is read with coda 2.22 different?

$ strings GOME_xxx_1B_M01_20210428220254Z_20210428220554Z_N_O_20210428233043Z | grep SENSING_START SENSING_START = 20210428220254Z SENSING_START_THEORETICAL = 20210428214200Z

$ ./level1bdump_test.py Reading: GOME_xxx_1B_M01_20210428220254Z_20210428220554Z_N_O_20210428233043Z MPHR.SENSING_START 672962574.0 year, month, day, hour, minute, second, millis 2021 4 28 22 2 17 0 SENSING_START_datetime 2021-04-28 22:02:17

#!/usr/bin/env python3
import coda
import datetime

if __name__ == "__main__":
    """ """

    filename = 'GOME_xxx_1B_M01_20210428220254Z_20210428220554Z_N_O_20210428233043Z'
    print ('Reading: ' + filename)

    # Open file
    fh = coda.open (filename)

    # Get Sensing Start from MPHR
    MPHR = coda.fetch (fh, 'MPHR')
    print ('MPHR.SENSING_START', MPHR.SENSING_START)

    # Convert into parts
    [year, month, day, hour, minute, second, millis] = coda.time_double_to_parts_utc (MPHR.SENSING_START)
    print ('year, month, day, hour, minute, second, millis', year, month, day, hour, minute, second, millis)

    # Make a datetime object from the parts
    SENSING_START_datetime = datetime.datetime (year, month, day, hour, minute, second, millis)
    print ('SENSING_START_datetime', SENSING_START_datetime)

    fh.close()

[svniemeijer]

Please post questions on our forum. GitHub is only for actual issues.

The problem is that you should be using coda.time_double_to_parts and not coda.time_double_to_parts_utc. The time() coda expression function. (as mentioned in https://stcorp.github.io/codadef-documentation/EPS/types/MPHR_v2.html) is also leap-second unaware.

For a proper definition of how to treat the leap-second unaware double time value of CODA have a look at Section 3.3.3 of the GEOMS standard. What is described there for the MJD2K also holds for the CODA time values.

The 'utc' version of the coda time functions is only provided as a utility function, but is not used in any of the coda reading routines itself.

[tuinder]

I posed it as a question, but I consider it a bug.

If you think it is intended behaviour of the function, then please provide a doc string for both the functions so that the user can learn and understand the difference.

In [1]: import coda       

In [2]: coda.time_double_to_parts?                                                                                                                                                                                
Signature: coda.time_double_to_parts(d)
Docstring: <no docstring>
File:      /usr/local/free/installed/coda-2.22-fc32/lib64/python3.8/site-packages/coda/__init__.py
Type:      function

In [3]: coda.time_double_to_parts_utc?                                                                                                                                                                            
Signature: coda.time_double_to_parts_utc(d)
Docstring: <no docstring>
File:      /usr/local/free/installed/coda-2.22-fc32/lib64/python3.8/site-packages/coda/__init__.py
Type:      function

[svniemeijer]

For the functions that are a direct mapping of the C functions, you should look at the documentation of the C interface.

I do agree, however, that we should add some information on how to decode the time values that are returned by CODA (i.e. that these are leap second unaware). I will add a separate issue on this.