[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


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.