Re: [netcdf-java] problem with times in PSD dataset

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/>
  • 2012 messages navigation, sorted by:
    1. Thread
    2. Subject
    3. Author
    4. Date
    5. ↑ Table Of Contents
  • Search the netcdf-java archives: