2nd netCDF file getting the wrong time stamp

[ryofurue]

In the following example, the second file acquires the wrong time value, apparently taking it from the first file:

$ pyferret
 	NOAA/PMEL TMAP
 	PyFerret v7.63 (optimized)
 	Darwin 19.6.0 - 12/10/21
 	15-Sep-23 15:14

yes? set data tmp1.nc
yes? set data tmp2.nc
yes? list/format=(G0)/d=1 t[gt=vm]
             VARIABLE : T
                        axis TIME
             FILENAME : tmp1.nc
             BAD FLAG : -1.E+34
             TIME     : 06-NOV-2014 07:00:00
735544.29166666663  !!! <- .291...
yes? list/format=(G0)/d=2 t[gt=vm]
             VARIABLE : T
                        axis TIME
             FILENAME : tmp2.nc
             BAD FLAG : -1.E+34
             TIME     : 06-NOV-2014 07:00:00  !!! WRONG time
735544.29166666663  !!! <- .291...  WRONG
yes? cancel data/all  !!!--- Swap the order ---
yes? set data tmp2.nc
yes? set data tmp1.nc
yes? list/format=(G0)/d=2 t[gt=vm]
             VARIABLE : T
                        axis TIME
             FILENAME : tmp1.nc
             BAD FLAG : -1.E+34
             TIME     : 06-NOV-2014 08:00:00  !!! WRONG time
735544.33333333337  !!! <- .333...  WRONG
yes? list/format=(G0)/d=1 t[gt=vm]
             VARIABLE : T
                        axis TIME
             FILENAME : tmp2.nc
             BAD FLAG : -1.E+34
             TIME     : 06-NOV-2014 08:00:00
735544.33333333337  !!! <- .333...
yes?

I'm attaching a ZIP archive that includes the two netCDF files.
tmp-ncfiles.zip

[ACManke]

Coordinates are stored, and used internally, using double precision. On opening datasets, the coordinate axes are tested to see if an identical axis has already been defined. That testing included some single-precision comparisons between coordinates. In this case, double precision is in fact needed to distinguish between the two axis definitions. This is corrected, and the fix will be available in future releases.

[ryofurue]

Thank you for your response! Even though the underlying dataset starts from the year 2000 or so and uses "hours" , the old OPeNDAP data server we use presents its time axis as "days since 0001-01-01". When I saved time slices one timestep at a time, this problem surfaced.

[ACManke]

This is fixed in fmt/src/cd_clean_grids.F.

Coordinate data is always stored in double precision, and analysis computations and checking for duplicate coordinates are done using double precision. When a new dataset is initialized the code tests whether an axis is already defined by some other dataset. For some reason this duplicate-line test was done in single precision. If the incoming axis is defined in double precision, do this check using double precision.