5.5.2: CoordinateAxis1DTime::getCoordBoundsDate returns nonsensical bounding dates when axis size equals 1

[tombrauer]

Versions impacted by the bug

v5.x

What went wrong?

CoordinateAxis1DTime::getCoordBoundsDate returns nonsensical bounding dates when CoordinateAxis1DTime::getSize is equal to 1. It seems like the logic in CoordinateAxis1DTime::getCoordBoundsDate is predicated on the axis size being greater than 1. Should my code check axis size == 1 before calling CoordinateAxis1DTime::getCoordBoundsDate or could the logic in CoordinateAxis1DTime::getCoordBoundsDate be more robust?

Remove the txt extension from example files below. NWRFC_2017-12-31T2300_to_2018-01-01T0000.nc4.txt 01.nc.txt

Relevant stack trace

No response

Relevant log messages

No response

If you have an example file that you can share, please attach it to this issue.

If so, may we include it in our test datasets to help ensure the bug does not return once fixed? Note: the test datasets are publicly accessible without restriction.

Yes

Code of Conduct

• [X] I agree to follow the UCAR/Unidata Code of Conduct

[haileyajohnson]

What behavior would you expect/want if the size of the axis=1? There aren't technically any bounds on the coordinate if there is only one coordinate. These are the options as I see it:

• return null
• return an array of size two with the same, single coordinate repeated twice
• throw an exception

We're open to other suggestions of how to handle it as well.

[tombrauer]

I ran the same test with a grib file and curiously that behaves differently than netCDF (maybe due to the underlying IOSP implementation?). The grib file behaves like the second approach you describe by returning an array of size two with the same, single coordinate repeated twice. See sample file below.

MRMS_GaugeCorr_QPE_01H_00.00_20170102-120000.grib2.txt

The second approach is what works best for my code, but if you decide to handle in another way, I can add appropriate handling logic.