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.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>
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-j...@unidata.ucar.edu
<mailto: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
_______________________________________________
CF-metadata mailing list
CF-metadata@cgd.ucar.edu
http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
_______________________________________________
CF-metadata mailing list
CF-metadata@cgd.ucar.edu
http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
