NOTICE: This version of the NSF Unidata web site (archive.unidata.ucar.edu) is no longer being updated.
Current content can be found at unidata.ucar.edu.
To learn about what's going on, see About the Archive Site.
NOTICE: This version of the NSF Unidata web site (archive.unidata.ucar.edu) is no longer being updated.
Current content can be found at unidata.ucar.edu.
To learn about what's going on, see About the Archive Site.
Hi, I have seen similar issues (time values being out by a second or two). I was wondering whether it's something to do with udunits and calculating dates on the basis of "units since XXXXXX". I seem to remember an earlier conversation on this list (or maybe on the CF list) concerning how udunits defines the length of certain time-spans (e.g. a month) and wondered whether this might be the issue? Jonathan Gregory recommended against using "months since" and "years since" and sticking to seconds or days to avoid ambiguities in the length of a month/year. But maybe this is a red herring. Whatever the issue is I'd be very keen to understand it as it's affecting me too! Cheers, Jon On Mon, May 12, 2008 at 9:31 PM, Sachin Kumar Bhate <skbhate@xxxxxxxxxxxxxxx> wrote: > John, > > The NcML file shown below attempts to aggregate time series files, > overriding > the time values for each 'time' variable. > > The aggregation works great and I can access the time values as well, > but I see that there is loss of precision in the new time values, when I > access > values for a coordinate data variable. > > For example: > > <<<< > URI = > 'http://www.gri.msstate.edu/rsearch_data/nopp/test_agg_precision.ncml'; > String var="T_20"; > > GridDataset gid = GridDataset.open(URI); > GeoGrid Grid = gid.findGridByName(var); > GridCoordSys GridCoordS = (GridCoordSys) Grid.getCoordinateSystem(); > > java.util.Date d[] = GridCoordS.getTimeDates(); > > System.out.println("DateString: "+d[0].toGMTString()); > >>>>> > > The output from the above code for the 1st time value in the java Date > array. > > DateString: 5 Dec 1989 18:59:59 GMT > > But, the correct value should be > > DateString: 5 Dec 1989 19:00:00 GMT > > > Just out of curiosity I tried to print the 1st time value being read > from the NcML, > by 'ucar.nc2.ncml.NcmlReader.readValues()'. I get, > > Start = 47865.79166666651; (Parsed as double) > > but, the 1st start value specified in NcML is '47865.7916666665110000'. > > Don't care about the tailing '0s', but the digit '1' in the 12th decimal > place is being dropped and may be causing this > problem. > > Although, parsing it as a 'BigDecimal' does read in the correct value. > > Start-BigDecimal: 47865.7916666665110000 > > > I am just guessing here, I am not sure if this is what causing the > precision problem. > > Will appreciate your help. > > thanks.. > > Sachin > > -- > Sachin Kumar Bhate, Research Associate > MSU-High Performance Computing Collaboratory, NGI > John C. Stennis Space Center, MS 39529 > http://www.northerngulfinstitute.org/ > > > > _______________________________________________ > netcdf-java mailing list > netcdf-java@xxxxxxxxxxxxxxxx > For list information or to unsubscribe, visit: > http://www.unidata.ucar.edu/mailing_lists/ > -- -------------------------------------------------------------- Dr Jon Blower Tel: +44 118 378 5213 (direct line) Technical Director Tel: +44 118 378 8741 (ESSC) Reading e-Science Centre Fax: +44 118 378 6413 ESSC Email: jdb@xxxxxxxxxxxxxxxxxxxx University of Reading 3 Earley Gate Reading RG6 6AL, UK --------------------------------------------------------------
netcdf-java archives: