[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[netCDF #FXL-473157]: ncdump -t invalid time strings

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