In the last 2 years alone, I've encountered a number of datasets ranging from reanalysis to climatologies to current ocean models that do utilize date from 1-1-1. While I agree that ISO8601 is probably a "better" system, it's not the one a lot of applications used when they were written. I think Don's right: As long as it works as it did before, and probably with more consensus and discussion prior to change, there needs to be backwards compatibility, even if there's a default selected.
gerry On Wed, Dec 5, 2012 at 1:25 PM, John Caron <ca...@unidata.ucar.edu> 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.mur...@noaa.gov <mailto:don.mur...@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> >>> >>> >>> <http://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/> >>> >>> <http://www.esrl.noaa.gov/psd/**people/don.murray/<http://www.esrl.noaa.gov/psd/people/don.murray/> >>> > >>> >>> ______________________________**___________________ >>> netcdf-java mailing list >>> netcdf-j...@unidata.ucar.edu >>> <mailto:netcdf-java@unidata.**ucar.edu<netcdf-j...@unidata.ucar.edu> >>> > >>> For list information or to unsubscribe, visit: >>> >>> http://www.unidata.ucar.edu/__**mailing_lists/<http://www.unidata.ucar.edu/__mailing_lists/> >>> >>> <http://www.unidata.ucar.edu/**mailing_lists/<http://www.unidata.ucar.edu/mailing_lists/> >>> > >>> >>> >>> >> > ______________________________**_________________ > netcdf-java mailing list > netcdf-j...@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@cgd.ucar.edu http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata