Due to the current gap in continued funding from the U.S. National Science Foundation (NSF), the NSF Unidata Program Center has temporarily paused most operations. See NSF Unidata Pause in Most Operations for details.

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

John-

On 12/5/12 12:25 PM, John Caron wrote:

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.


As long as it works as it did before. ;-)


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.
As climate datasets like reanalyses push further and further back into the past, we need to have support for dates that cross the Julian/Gregorian line. A tree ring dataset that goes back before 1500 would need support for this as well. 


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.
Not all software can easily adapt to this. It's great that the CDM can handle this, but there is legacy software that has worked well for a long time that can't easily be upgraded. Sometimes you need to consider what is out there than what is "right". 


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>
I agree that udunits should not be used for calendaring, but even Joda time has support for times since 1-1-1, so restricting the Julian/Gregrorian calendar usage isn't necessary. 


In short, we should rely on clear encoding standards (eg ISO8601) with
reference software, rather than implementations like udunits that
eventually go away.
PS: I think ill cross post to cf, just to throw some gasoline on the
fire ;), and maybe some broader viewpoints.
It would be good to get as much input as possible before changing how things have worked for a long time. 

Don


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>





            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/>






_______________________________________________
netcdf-java mailing list
netcdf-java@xxxxxxxxxxxxxxxx
For list information or to unsubscribe, visit:
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/
  • 2012 messages navigation, sorted by:
    1. Thread
    2. Subject
    3. Author
    4. Date
    5. ↑ Table Of Contents
  • Search the netcdf-java archives: