Hi Cecelia:
Thanks for this information. A few questions:
* So you are not supporting "standard Gregorian calendar" even though
thats the CF default?
* Do modelers need to match "historical dates"? If so, what calendar do
they use?
* Is the time library suitable to be released seperate from the ESMF
code, eg as standalone C++?
John
On 12/5/2012 3:01 PM, Cecelia DeLuca wrote:
> Hi John and all,
>
> ESMF has a mature time management library with calendars that are commonly
> used in climate/weather/related modeling. It supports the following: 360
> day,
> no leap, Gregorian (proleptic), Julian, Julian day, modified Julian day,
> and custom
> (including custom calendars that may change the length of days). ESMF,
> like CESM,
> doesn't support the standard Gregorian calendar because it doesn't make
> sense for modeling groups who may need to cross the Julian/Gregorian
> weirdness line (we've never gotten a request to support standard
> Gregorian from
> modelers). ESMF has calendar, time, time interval, clock, and alarm
> constructs,
> can run time forward or backward, and prints times and time intervals in
> ISO8601
> format. CESM/CAM, NASA, NOAA, Navy and other codes use it.
>
> The most complete interface to the time lib is Fortran, and there are
> some basic
> time functions exposed in C (the lib is actually written in C++).
> However, we could
> wrap the time functions in Python and include them in ESMP, which is
> currently a
> set of ESMF regridding functions wrapped in Python. We could probably do
> that
> in the late/winter spring timeframe, with some guidance on what
> functions were
> desired and a pass through our prioritization board.
>
> Best,
> -- Cecelia
>
>
> On 12/5/2012 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
>
Received on Thu Dec 06 2012 - 12:48:57 GMT
