[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[netCDF #FXL-473157]: ncdump -t invalid time strings
- Subject: [netCDF #FXL-473157]: ncdump -t invalid time strings
- Date: Fri, 21 Jun 2013 13:02:11 -0600
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