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.
In the last 2 years alone, I've encountered a number of datasets ranging
from reanalysis to climatologies to current ocean models that do utilize
date from 1-1-1. While I agree that ISO8601 is probably a "better" system,
it's not the one a lot of applications used when they were written. I think
Don's right: As long as it works as it did before, and probably with more
consensus and discussion prior to change, there needs to be backwards
compatibility, even if there's a default selected.
gerry
On Wed, Dec 5, 2012 at 1:25 PM, John Caron <caron@xxxxxxxxxxxxxxxx> 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@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>
>>>
>>>
>>> <http://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/>
>>>
>>> <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@unidata.**ucar.edu<netcdf-java@xxxxxxxxxxxxxxxx>
>>> >
>>> For list information or to unsubscribe, visit:
>>>
>>> http://www.unidata.ucar.edu/__**mailing_lists/<http://www.unidata.ucar.edu/__mailing_lists/>
>>>
>>> <http://www.unidata.ucar.edu/**mailing_lists/<http://www.unidata.ucar.edu/mailing_lists/>
>>> >
>>>
>>>
>>>
>>
> ______________________________**_________________
> 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/>
netcdf-java archives: