⇐ ⇒

[CF-metadata] [netcdf-java] problem with times in PSD dataset

From: Cathy Smith <cathy.smith>
Date: Thu, 06 Dec 2012 16:34:13 -0700

John
There is some meteorological data that is available pre-Gregorian
calendar (paleo data, some temperature datasets) and of course there are
other scientific fields where data is pre-1500 (e.g. astronomy,
archeology) . Given that netCDF files with data dates spanning ~1550 probably already exist and the large number of preexisting files that
use the 1-1-1 base (we have over 2000), it doesn't seem reasonable to
request that files be changed to accommodate what is essentially a bug;
the date values we store are correct. We started using the 1-1-1 base in the mid
1990's (almost 20 years ago) as part of the COARDS (now CF) agreed upon standard.
It is reasonable for us to consider future changes but I don't think it reasonable for us to have to change our files because the Java interface is not backwards compatible.

Cathy Smith
NOAA/ESRL PSD

On 12/5/12 12:25 PM, John Caron wrote:
> Hi all:
>
> Its probably the right thing to do to make gregorian ("Mixed
> Gregorian/Julian calendar") the default calendar for COARDS/CF, for
> backwards compatibility. However, CDM may leave proleptic_gregorian
> (ISO8601) as its default.
>
> And I would strongly suggest that data writers stop using "time since
> 1-1-1". Ive never seen a dataset where "time since 1-1-1" using the
> mixed gregorian calendar was actually needed. If any one has a real
> example, Id like to hear about it.
>
> If you really need "historical accuracy", then put in an ISO8601
> formatted string, and an explicit calendar attribute. CDM handles
> those ok. CF should be upgraded to allow ISO strings also. "time since
> reference date" is not good for very large ranges of time.
>
> Ill just add that udunits never wanted to be a calendaring library,
> and shouldnt be used anymore for that. Im relying on joda-time (and
> its successor threeten) to be the expert in calendering, so i dont
> have to. I think the netcdf-C library now uses some CDAT (?) code for
> its calendaring, but Im sure theres other standard libraries that
> could be used. Anyone have candidate libraries in C or Python for
> robust calendering>
>
> In short, we should rely on clear encoding standards (eg ISO8601) with
> reference software, rather than implementations like udunits that
> eventually go away.
>
> John
>
> PS: I think ill cross post to cf, just to throw some gasoline on the
> fire ;), and maybe some broader viewpoints.
>
> On 12/5/2012 10:24 AM, Don Murray (NOAA Affiliate) wrote:
>> 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 at noaa.gov <mailto:don.murray at noaa.gov>> 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 at unidata.ucar.edu <mailto:netcdf-java at unidata.ucar.edu>
>>> For list information or to unsubscribe, visit:
>>> http://www.unidata.ucar.edu/__mailing_lists/
>>> <http://www.unidata.ucar.edu/mailing_lists/>
>>>
>>>
>>
> _______________________________________________
> CF-metadata mailing list
> CF-metadata at cgd.ucar.edu
> http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata

-- 
----------------------------------------------
NOAA/ESRL PSD and CIRES CDC
303-497-6263
http://www.esrl.noaa.gov/psd/people/cathy.smith/
Emails about data/webpages may get quicker responses from emailing 
esrl.psd.data at noaa.gov
Received on Thu Dec 06 2012 - 16:34:13 GMT

This archive was generated by hypermail 2.3.0 : Tue Sep 13 2022 - 23:02:41 BST

⇐ ⇒