Time Coordinate Detection Failure when multiple numpy.datetime64 with units exist in the variables.

[david-sh-csiro]

Using dataset.ems.time_coordinate on some datasets yields an unexpected time coordinate.

When multiple numpy.datetime64 that have units exist within the dataset variables, the logic for looking up time coordinates can pick the unexpected one.

For the below dataset, it will find the 'forecast_reference_time' as the time coordinate variable instead of 'time'.

Excerpt of the dataset.

        int64 forecast_reference_time(time) ;
                forecast_reference_time:units = "seconds since 2024-02-28 00:00:00" ;
                forecast_reference_time:standard_name = "forecast_reference_time" ;
                forecast_reference_time:calendar = "gregorian" ;
        float sfc_temp(time, lat, lon) ;
                sfc_temp:standard_name = "surface_temperature" ;
                sfc_temp:long_name = "surface temperature" ;
                sfc_temp:units = "degrees C" ;
                sfc_temp:coordinates = "time, lat, lon" ;
        double time(time) ;
                time:axis = "T" ;
                time:bounds = "time_bnds" ;
                time:calendar = "gregorian" ;
                time:long_name = "time" ;
                time:standard_name = "time" ;
                time:units = "days since 1970-01-01 00:00:00 00" ;
                time:coordinate_type = "time" ;

Looking at the source code it appears to prioritise finding the first variable that is a numpy.datatime64 with units over things like the CF convention standard name.

[mx-moth]

Detection could be improved, no argument there, but this is always going to be a losing battle.

For now, we could potentially rank time coordinates based on the number of ways they indicate that they are a time coordinate. For example we could add one point for each matching attribute, then picking the coordinate with the most points.

The actual problem is that the concept of a dataset time coordinate doesn't strictly speaking exist. If there is a variable with the same name as a dimension then it is assumed that this variable is the coordinate for this dimension. In that sense the time dimension has a time coordinate variable, and this variable happens to have a datetime type. Two issues present themselves here:

• There is nothing stopping a dataset having multiple dimensions with datetime-typed coordinate variables.
• We already use datasets where the dimension name doesn't match the coordinate name (e.g. record vs time).

According to the CF conventions, a variable uses the "coordinates" attribute to indicate which coordinates apply to itself. Different variables may use different coordinates for the same set of dimensions.

There are examples of a dataset having multiple time coordinates: the real world datetime for that time index, and the most recent observation datetime that this time index is extrapolated from. These are both valid coordinates, they both have use, they both apply to the time dimension, and they both are datetimes.

Additionally, there are datasets that don't have a time coordinate because they are just bathymetry or something. Currently this is handled by raising a NoSuchCoordinateError. However there is an argument that this isn't an error, there is nothing saying that a dataset must have a time coordinate.

I don't know what the correct approach is for handling the concept of a singular time coordinate for a dataset.