[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


NOTE: All email exchanges with Unidata User Support are recorded in the Unidata inquiry tracking system and then made publicly available through the web. If you do not want to have your interactions made available in this way, you must let us know in each email you send to us.