All,
On 12/6/2012 5:49 PM, Dave Allured - NOAA Affiliate wrote:
> All,
>
> I agree that the current calendar definitions and usage have a lot of
> problems. Following are some proposals that are geared towards both
> accuracy and backward compatibility.
>
> 1. Please, NO default calendar. Starting with the next CF version,
> the calendar attribute should be required on all time coordinate
> variables.
This is an appealing option. It works and removes some of the "CF is
for data, not models"
issues with the current default.
>
> 2. Define a new and unique name for the mixed Julian/Gregorian
> calendar. My favorite would be "julian-gregorian". I could tolerate
> "mixed julian-gregorian".
This is good as well.
>
> 3. Recommend that mixed Julian/Gregorian never be used, except (a) in
> genuine historical data sets that properly need to span the crossover;
> and (b) to facilitate backward compatibility in existing data sets.
Yup, still good.
>
> 4. Redefine "gregorian" to mean ONLY the proper Gregorian calendar
> starting on the crossover date 1582 October 15. Add the formal
> constraint on this calendar, that any usage with dates earlier than
> the crossover is prohibited. Note that many existing data sets are
> automatically compatible with this constraint, with no changes needed.
Up to the data folks ...
>
> 5. Recommend gregorian, NOT proleptic_gregorian, as the CF preferred
> calendar for dates associated with the modern era.
Don't see how this works for climate modelers who need a continuous
calendar, and
will continue the divide between models and data.
Cecelia
>
> 6. Stop using "standard" as a calendar name. Please be explicit.
>
> --Dave
>
> On Thu, Dec 6, 2012 at 2:37 PM, John Caron <caron at unidata.ucar.edu> wrote:
>> Hi Steve, Cecelia:
>>
>> I agree we should move to a better default calendar, probably
>> proleptic_gregorian. We are stuck with mixed Gregorian for previous CF
>> versions.
>>
>> I think we just need a proposal that says "As of version X, the default
>> calender is proleptic_gregorian. You should explicitly add the calendar
>> attribute for clarity. Udunits is no longer considered to be the reference
>> software for date/time."
>>
>> It would be nice to add advice to the user about calendar tradeoffs and how
>> to do historical date matching for modelers, assuming we have useful things
>> to say.
>>
>> I wonder if allowing ISO formatted strings in place of / in addition to the
>> "time since reference date" form might be useful for historical time
>> matching?
>>
>> Arguably having calendar reference libraries in Python and Java would be
>> sufficient, possibly Python is preferable even to one in C.
>>
>> John
>>
>> On 12/6/2012 1:45 PM, Cecelia DeLuca wrote:
>>>
>>> Hi John and all,
>>>>
>>>> Thanks for this information. A few questions:
>>>>
>>>> * So you are not supporting "standard Gregorian calendar" even though
>>>> thats the CF default?
>>> Correct, the climate modelers that we work with don't use it. AFAIK the
>>> decision of
>>> CESM was to reject the CF default as unreasonable for modeling and use
>>> proleptic
>>> Gregorian. GFDL might support it, I don't know.
>>>
>>> We could probably add standard Gregorian as a new calendar if people on
>>> the
>>> data side needed it. However, we would be happier to join Steve in
>>> putting
>>> a stake in its heart!
>>>>
>>>> * Do modelers need to match "historical dates"? If so, what calendar
>>>> do they use?
>>> I think the calendar used would depend on what was supported by the
>>> model and
>>> configuration, as well as the form of the date. If you wanted to
>>> represent the date
>>> of something like a volcanic eruption you could probably make it work
>>> with most
>>> of the calendars.
>>>
>>>> * Is the time library suitable to be released seperate from the ESMF
>>>> code, eg as standalone C++?
>>> The time library can be used apart from other ESMF interfaces, and some
>>> modeling groups do use it that way. I don't think we'd be willing to
>>> extract that
>>> part and support a separate build. We did that years ago and it was a
>>> pain
>>> to maintain. (We could try to isolate the documentation though, so users
>>> didn't have to wade through the whole reference manual to find the API.)
>>>
>>> With ESMP(ython), the scope of the interface is much smaller than
>>> ESMF proper and I think Ryan could set time functions up nicely. It might
>>> make sense to represent it as a separate python package in that approach.
>>> Would python work for you, or would you really prefer C?
>>>
>>> - Cecelia
>>>
>>>> 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
>>>>>
>>>> _______________________________________________
>>>> 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
> _______________________________________________
> CF-metadata mailing list
> CF-metadata at cgd.ucar.edu
> http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
--
===================================================================
Cecelia DeLuca
NESII/CIRES/NOAA Earth System Research Laboratory
325 Broadway, Boulder 80305-337
Email: cecelia.deluca at noaa.gov
Phone: 303-497-3604
Received on Fri Dec 07 2012 - 07:56:52 GMT
