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

[netCDF #OZZ-222928]: Re: use of "nctime.c" code in NCL

Hi Mary,

> Thanks for your iterations on this. I think I found a bug, please see my 
> comments towards the end.

Thanks for reporting the bug!  I guess our testing with fractions of days in 
ncdump/tst_calendars.cdl wasn't adequate to catch this, so we'll add your 
example
to that and get it working correctly.  I hope I can get to this and supply a 
fix 
next week.

--Russ

> On Mar 21, 2011, at 8:35 AM, Russ Rew wrote:
> 
> >>> Just FYI, I think there's a more recent version of the cdtime
> >>> functionality in a Python library, also from LLNL/PCMDI.
> >>
> >> I downloaded cdat last night and was trying to see if the
> >> code had been updated.  Did you un-Pythonize the code yourself, or find
> >> a pure C version somewhere? Also, did you add support for the 366
> >> calendar? On first glance, I don't see reference to this in the
> >> cdat code I downloaded.
> >
> > I started from Bob Drach's original pure C version and added support for
> > the 366-day  calendar.  The ncdump/nctime.c in  the current distribution
> > has mention of that in the first block of comments.
> 
> Okay thanks. I did see these comments, but I couldn't find the pure C
> version in the CDAT code, so I wasn't sure that was done by you.
> 
> >
> >> The thing I'm wondering about is how to get minutes and seconds out
> >> of the code. I see the cdFractional stuff, and some code that
> >> gets minutes/seconds out of that, but was this intentionally
> >> left out for ncdump? The reason I ask is that I see code like this
> >> in nctime.c:
> >>
> >>                case cdFraction:
> >>                        cdError("invalid unit in conversion");
> >>                        break;
> >>                }
> >>
> >> that I don't see in the cdat version.
> >
> > No, ncdump will provide minutes and seconds.  For example, if I have on
> > input
> >
> >  netcdf tst {
> >  dimensions:
> >    time = 1;
> >  variables:
> >    double t1_days(time);
> >       t1_days:units = "days since 1500-1-1";
> >  data:
> >       t1_days = 185900.523275463;     // close to 2009-01-01 12:33:31
> >       t1_days:calendar = "standard" ; // mixed julian-gregorian
> >  }
> >
> > then the output from ncdump -t is as expected:
> >
> >  t1_days = "2009-01-01 12:33:31.000002" ;
> >
> > where there's a small epsilon because a second can't be represented
> > exactly in a terminating decimal as a fraction of a day.
> 
> I think I found a bug, that seems like the minutes and seconds aren't being 
> calculated from the original relative units.
> 
> For example, I have the following netcdf file; note the minutes and seconds:
> 
> netcdf tst {
> dimensions:
> time = 1 ;
> variables:
> float time(time) ;
> time:units = "seconds since 2008-06-04T00:15:03Z" ;
> data:
> 
> time = 1 ;
> }
> 
> ncdump -t tst.nc gives me:
> 
> % ncdump -t tst.nc
> netcdf tst {
> dimensions:
> time = 1 ;
> variables:
> float time(time) ;
> time:units = "seconds since 2008-06-04T00:15:03Z" ;
> data:
> 
> time = "2008-06-04 00:00:1.000000" ;
> }
> 
> Since the relative min/sec start at 15:03 and not 00:00, shouldn't the string 
> version of time be:
> 
> time = "2008-06-04 00:15:4.000000" ;
> 
> utCalendar gives me what I expect, but cdtime doesn't.
> 
> --Mary
> 
> 
> 
> 
> 
> 
> >
> > --Russ
> 
> 

Russ Rew                                         UCAR Unidata Program
address@hidden                      http://www.unidata.ucar.edu



Ticket Details
===================
Ticket ID: OZZ-222928
Department: Support netCDF
Priority: Normal
Status: Closed