On 12/6/2012 1:37 PM, John Caron 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."
>
You've about nailed it here. Perhaps adding that a zero-reference date
that lies this side of 1500 AD can ensure that this confusion does not
effect your files.
> 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.
We could even point them to the Wikipedia discussion of the mess:
https://en.wikipedia.org/wiki/Gregorian_calendar
>
> 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?
I suspect that the "historical matching" is never going to be a
well-posed problem. If we regard the date-time as nothing more than a
piece of metadata attached to an XYZ grid, then "matching" is a
well-posed problem of finding the cross walk between different metadata
vocabularies. But if we regard time as a continuous coordinate variable
and date-time as a way to express that coordinate in ASCII, then
matching is a pathological problem, because the blended Gregorian-Julian
calendar has an 11 day discontinuity ... and the time of the
discontinuity varies depending on what country the event occurred in.
Not worth the trouble imho.
- Steve
>
> 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
Received on Thu Dec 06 2012 - 16:13:39 GMT
