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 Gerry- On 12/5/12 9:42 AM, Gerry Creager - NOAA Affiliate wrote:
There are other datasets with reference to 1-1-1. I've seen them most recently in some ocean models.
And the ESRL/PSD NCEP reanalysis datasets use it. Don
On Wed, Dec 5, 2012 at 10:16 AM, Don Murray (NOAA Affiliate) <don.murray@xxxxxxxx <mailto:don.murray@xxxxxxxx>> wrote: John- I meant to send this to support-netcdf-java, but perhaps others on the list might have the same problem. On 12/4/12 4:51 PM, John Caron wrote: On 12/4/2012 4:09 PM, Don Murray (NOAA Affiliate) wrote: Hi- I was just trying to access the NOAA/ESRL/PSD Outgoing Longwave Radiation (OLR) data using netCDF-Java 4.3 ToolsUI and noticed that the times are wrong. If you open: dods://www.esrl.noaa.gov/psd/__thredds/dodsC/Datasets/__uninterp_OLR/olr.day.mean.nc <http://www.esrl.noaa.gov/psd/thredds/dodsC/Datasets/uninterp_OLR/olr.day.mean.nc> in the ToolsUI grid viewer, the last time in the file is shown as 2012-12-04 00Z. However, the last time in the file is actually 2012-12-02 00Z. Here is the time variable in that file: double time(time=3989); :units = "hours since 1-1-1 00:00:0.0"; :long_name = "Time"; :actual_range = 1.7540448E7, 1.763616E7; // double :delta_t = "0000-00-01 00:00:00"; :avg_period = "0000-00-01 00:00:00"; :standard_name = "time"; :axis = "T"; netCDF-Java 4.2 and ncdump -t -v time (C version) show the correct date/times. hours from 1-1-1 is rather problematic, since you are crossing the julian/gregorian weirdness line (i think thats the technical term ;) Im guessing the trouble lies here: "Default calendar: for udunits, and therefore for CF, the default calendar is gregorian ("Mixed Gregorian/Julian calendar"). For CDM, the default calendar is proleptic_gregorian (ISO8601 standard). This only matters for dates before 1582." Joda time supports the GJ calendar (Historically accurate calendar with Julian followed by Gregorian) which seems it would be backward compatible with the CF/udunits. Perhaps that should be the default for backward compatibility. I have to say relying uncritically on a calendar implementation like udunits is a mistake. putting the reference date unnecessarily to include the problem is, um, unnecessary. But it is historically accurate. For climate datasets, this would be important. is there any way those files can be updated? specifying the gregorian calendar explicitly should do it, but changing to use a reference date after 1582 would be much better. How's your FORTRAN? ;-) I'm not sure why this was chosen originally, but it doesn't seem reasonable to make people change their datasets. Does anyone else on the list know of datasets (other than climatologies) that might use a reference of 1-1-1 that will be affected by this change? BTW, is there an easier way to see human readable dates through toolsUI than loading it into the grid viewer (akin to ncdump -t)? open in coordSys tab; in bottom table, select time coord, right-click and choose "show values as date" Thanks, that's easier. Don -- Don Murray NOAA/ESRL/PSD and CIRES 303-497-3596 <tel:303-497-3596> http://www.esrl.noaa.gov/psd/__people/don.murray/ <http://www.esrl.noaa.gov/psd/people/don.murray/> _________________________________________________ netcdf-java mailing list netcdf-java@xxxxxxxxxxxxxxxx <mailto:netcdf-java@xxxxxxxxxxxxxxxx> For list information or to unsubscribe, visit: http://www.unidata.ucar.edu/__mailing_lists/ <http://www.unidata.ucar.edu/mailing_lists/>
-- Don Murray NOAA/ESRL/PSD and CIRES 303-497-3596 http://www.esrl.noaa.gov/psd/people/don.murray/
netcdf-java archives: