issue with decoding leap seconds

[jdkloe]

For the Aeolus L1B products I encountered one specific product for which a leap second was activated, probably by mistake. This highlighted that the coda python time_to_utcstring and time_to_string functions do not handle this in the correct way. The product AE_OPER_ALD_U_N_1B_20211127T235317020_005436015_018919_0001.DBL (baseline 12 NRT product) shows a leap second for BRC index 33, measurement index 21,22 and 23. coda.time_to_string decodes this as:

>>> print(coda.time_to_string(coda.fetch(fd,'geolocation',33,'measurement_aocs',21,'measurement_centroid_time')))
2021-11-29 00:00:00.121732

But this should have been: 2021-11-28 23:59:60.121732

coda.time_to_utcstring decodes this as

>>> print(coda.time_to_utcstring(coda.fetch(fd,'geolocation',33,'measurement_aocs',21,'measurement_centroid_time'))
2021-11-28 23:59:23.121732

So this result differs 37 seconds with the above result for the same input file.

[svniemeijer]

This is actually as intended. The time_to_string function is not leap-second aware, so it will never produce a time value with seconds=60.

As can be seen in the codadef documentation for this product the conversion to a floating point value is a simple conversion based on a fixed amount of seconds per day (i.e. leap-second unaware) and would be similar to using coda.time_parts_to_double. As also clarified in the CODA Time documentation you can't mix leap-second aware and leap-second unaware representations. So, if you really want to use leap-second aware time values, you would have to disable the auto-conversion to time values and construct a leap-second aware timestamp yourself based on the days, seconds, and microseconds fields.

Note also that the leap-second unaware conversion is the default behaviour for all products that coda supports. Changing this would introduce unwanted backward compatibility issues.

[jdkloe]

Thanks for explaining.

I think my issue here is that I could not find this CODA Time documentation page because there is no link to it on the coda python documentation which is my main programming language when I use coda.

In addition we also found that there actually is a bug in the L1b processor itself causing a date jump of 1 year in case a leap second occurs. Of course this is not a coda issue, but makes the interpretation of the mentioned L1B product more confusing.

[svniemeijer]

Good point. I will see whether we can add some cross-references in the documentation.