Hi folks,
With the 4.x version of ncdump one can use the -t option to request
output of time data as human-readable date-time strings rather than as
'raw' numbers (e.g. days since reference_date). This works well when
one is querying a primary time coordinate variable that possesses the
requisite netCDF attributes, e.g. units and calendar (as shown in the
CDL snippet below).
But it doesn't work so well for CF-compliant boundary variables (e.g.
time_bnds in our example) used to specify the cell bounds of coordinate
variables. The reason being that such boundary variables typically do
not replicate the relevant attributes attached to the 'parent'
coordinate variable.
dimensions:
time = UNLIMITED ; // (1800 currently)
lat = 216 ;
lon = 360 ;
bnds = 2 ;
variables:
double time(time) ;
time:bounds = "time_bnds" ;
time:units = "days since 1859-12-01" ;
time:calendar = "360_day" ;
time:axis = "T" ;
time:long_name = "time" ;
time:standard_name = "time" ;
double time_bnds(time, bnds) ;
// no attributes
This shortcoming can readily be overcome by duplicating the units and
calendar attributes on the time_bnds variable (usng, say, the ncatted
utility). But one can see that doing this would become a chore after a
while!
Naturally it wouldn't be right (or would it?) to encode CF rules within
the base netCDF libraries, so I wonder if there's a case for enhancing
the -t option in some way such that the user could specify the
associated variable from which to read requisite attributes. For
example, the extended command to print out the date-time strings of the
time_bnds variable might appear thus:
$ ncdump -v time_bnds -t time myfile.nc
Or, if it was necessary to maintain the unadorned -t option for
backwards compatibility:
$ ncdump -v time_bnds -T time myfile.nc
Any mileage in this suggestion?
Regards,
Phil
