Don
There are other datasets with reference to 1-1-1. I've seen them most
recently in some ocean models.
Gerry
On Wed, Dec 5, 2012 at 10:16 AM, Don Murray (NOAA Affiliate) <
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
> 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
> For list information or to unsubscribe, visit:
> http://www.unidata.ucar.edu/**mailing_lists/<http://www.unidata.ucar.edu/mailing_lists/>
>
