On 12/6/2012 4:09 PM, John Caron wrote:
> Hi Cathy:
>
> There no question that CF currently defaults to mixed gregorian
> calendar. The discussion is whether thats the best choice (probably
> not), and to advise users not to cross the discontinuity (eg store
> modern dates starting from 1-1-1).
>
> Im curious as to how you generate the dates that you store? That is,
> how do you know that they are correct?
>
Hi Cathy,
A question to add to John's:
* If a user made a time series plot of paleo data across the
Julian-Gregorian discontinuity, what expectations would he/she have
about how the time axis was labelled? Do you know of software that
will correctly label the time axis across a mixed Julian-Gregorian
time series?
- Steve
> John
>
> On 12/6/2012 4:34 PM, Cathy Smith (NOAA Affiliate) wrote:
>> 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
>>
> _______________________________________________
> CF-metadata mailing list
> CF-metadata at cgd.ucar.edu
> http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <
http://mailman.cgd.ucar.edu/pipermail/cf-metadata/attachments/20121206/42125ace/attachment-0001.html>
Received on Thu Dec 06 2012 - 17:35:40 GMT
