This archive contains answers to questions sent to Unidata support through mid-2025. Note that the archive is no longer being updated. We provide the archive for reference; many of the answers presented here remain technically correct, even if somewhat outdated. For the most up-to-date information on the use of NSF Unidata software and data services, please consult the Software Documentation first.
Hi Dave, Thanks for the bug report and example that demonstrates the problem. I've added this to our bug-tracking system, in case you want to follow progress on getting it fixed: https://bugtracking.unidata.ucar.edu/browse/NCF-259 As you've pointed out, it's not a very high priority, but we should nevertheless fix the bug. --Russ > Netcdf support, > > This is a very minor issue with ncdump. Ncdump -t outputs random > garbage characters in time strings, when large numeric values are > encountered. This occurs with both attributes and data variables. > Here are two output lines showing the problem: > > x:_FillValue = 9.96920996838687e+36 ; // "9¨Rÿ" > > time = "1998-01-01", "1998-01-01 03", "1998-01-01 06", "{ázÿ", > "1998-01-01 12" ; > > These resulted from the following CDL, run through ncgen, then ncdump -t: > > netcdf demo.time { > dimensions: > time = UNLIMITED ; // (5 currently) > variables: > double time(time) ; > time:units = "days since 1980-1-1 netcdf fxl { dimensions: time = UNLIMITED ; // (5 currently) variables: double time(time) ; time:units = "days since 1980-1-1 0:0:0" ; time:calendar = "gregorian" ; double x ; x:units = "days since 1980-1-1 0:0:0" ; x:calendar = "gregorian" ; x:_FillValue = 9.96920996838687e+36 ; data: time = 6575, 6575.125, 6575.25, 9.1111111111e+36, 6575.5 ; x = 6575 ; }0:0:0" ; > time:calendar = "gregorian" ; > double x ; > x:units = "days since 1980-1-1 0:0:0" ; > x:calendar = "gregorian" ; > x:_FillValue = 9.969209968386869e+36 ; > data: > time = 6575, 6575.125, 6575.25, 9.1111111110999999e+36, 6575.5 ; > x = 6575 ; > } > > The garbage characters change randomly with different invocations. I > get the same results with ncdump in versions 4.2.1.1 and 4.3.0, spot > tested on linux and mac platforms. > > This looks like failure to trap some kind of range error in a low > level time formatting routine. I would like to suggest detecting such > errors, and displaying either an error token (I like "***") or the > empty string in the bad position(s). > > Thanks for your consideration. > > --Dave > > Russ Rew UCAR Unidata Program address@hidden http://www.unidata.ucar.edu Ticket Details =================== Ticket ID: FXL-473157 Department: Support netCDF Priority: Normal Status: Closed