This archive contains answers to questions sent to Unidata support through mid-2025. Note that the archive is no longer being updated. We provide the archive for reference; many of the answers presented here remain technically correct, even if somewhat outdated. For the most up-to-date information on the use of NSF Unidata software and data services, please consult the Software Documentation first.
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