On 12/6/2012 11:48 AM, John Caron wrote:
Hi Cecelia:Thanks for this information. A few questions:* So you are not supporting "standard Gregorian calendar" even though thats the CF default?
John et. al.,We ought to fix this in ambiguity the CF specification. Your quotations around "standard Gregorian calendar" are, I assume, an acknowledgement that this calendar is no standard at all. Use of this calendar is an ancient pesky mistake in the udunits library from many, many years ago that just won't leave us alone. Lets purge it once and for all. Strangle it. Suffocate it. Eradicate it. Genocide for mixed Gregorian/Julian calendars!!!
* Do modelers need to match "historical dates"? If so, what calendar do they use?
If any modeler needs to do this, let them do it in the manner that a historian would -- manually figuring out the details of which calendar was in use when and where each piece of information was recorded. The mixed Gregorian/Julian calendar has (imho) no place in scientific work. The attempts to address the problem through code create more confusion than they clean up.
- ("tell us what you really think") Steve
* 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 commonlyused 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. DonOn Wed, Dec 5, 2012 at 10:16 AM, Don Murray (NOAA Affiliate) <[email protected] <mailto:[email protected]>> wrote: John-I meant to send this to support-netcdf-java, but perhaps others onthe 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 thecorrect date/times.hours from 1-1-1 is rather problematic, since you are crossingthe 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 defaultcalendar is gregorian ("Mixed Gregorian/Julian calendar"). ForCDM, 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 defaultfor 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 wouldbe 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[email protected] <mailto:[email protected]>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 [email protected] http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata_______________________________________________ CF-metadata mailing list [email protected] http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
_______________________________________________ CF-metadata mailing list [email protected] http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
