Hi Jonathan:
On 8/18/2011 9:41 AM, Jonathan Gregory wrote:
Dear John
http://www.unidata.ucar.edu/software/netcdf-java/CDM/DateTime.html
If there's interest, I can propose as a CF convention. Otherwise it
can remain a CDM extension.
Thank you for doing this. I think it's an attractive idea to have calendar
handling in CF time coordinates. One issue to be dealt with would be the
need to be able to process these strings using any programming language
which might be used to process CF-netCDF data. Could the software be ported
to other languages in which the netCDF lib exists?
As Jon said, it should be straightforward to develop an extension of
udunits (C library) to support this, once the specification is worked
out. However, at the moment, we are not sure of who/how/if this will be
done. A lot would depend on finding an open-source calendar libary in C
that does the right thing. We may be able to leverage the ESMF library.
In order to do calculations
with times, which are often necessary, we need to be able to convert them into
a form which has a fixed-length unit since a reference time (like udunits),
even though that isn't the most convenient way to express them.
I think that given two calendar dates in the same calendar, there will
be a well-defined # seconds between them. I think thats the essence of
whats needed.
What you have proposed for the syntax looks very sensible to me. I have some
minor points:
* A bit related to Don's: it would be good to allow SI prefixes, like udunits
does. For instance, ms is the usual SI symbol for millisecond.
Im not sure I can actually implement prefixes for calendar fields, since
in general that would violate the need for integers. millisecond makes
sense, but millihour doesnt.
* What happens if n months or n years since a certain date is not a valid
date in the calendar? You probably have a rule to resolve that. Most safely,
it should be an error to encode such a time, I suppose (e.g. 1 year since
29 Feb 2008). Do you insist that the ref data is valid in the calendar?
Very good question.
1) There are some dates that are invalid in some calendars eg 29 Feb
2009, and also apparently 1582-10-05 to 1582-10-14, as well as year 0 in
the gregorian calendar. So if you try to use those in the
calendar_field, you will get an error.
2) Then theres the question of "1 year since 29 Feb 2008". This is what
the library im using does, which seems right to me:
1 calendar years since 2008-02-29 00:00:00Z == 2009-02-28T00:00:00.000Z
2 calendar years since 2008-02-29 00:00:00Z == 2010-02-28T00:00:00.000Z
3 calendar years since 2008-02-29 00:00:00Z == 2011-02-28T00:00:00.000Z
4 calendar years since 2008-02-29 00:00:00Z == 2012-02-29T00:00:00.000Z
5 calendar years since 2008-02-29 00:00:00Z == 2013-02-28T00:00:00.000Z
6 calendar years since 2008-02-29 00:00:00Z == 2014-02-28T00:00:00.000Z
7 calendar years since 2008-02-29 00:00:00Z == 2015-02-28T00:00:00.000Z
8 calendar years since 2008-02-29 00:00:00Z == 2016-02-29T00:00:00.000Z
9 calendar years since 2008-02-29 00:00:00Z == 2017-02-28T00:00:00.000Z
10 calendar years since 2008-02-29 00:00:00Z == 2018-02-28T00:00:00.000Z
11 calendar years since 2008-02-29 00:00:00Z == 2019-02-28T00:00:00.000Z
12 calendar years since 2008-02-29 00:00:00Z == 2020-02-29T00:00:00.000Z
13 calendar years since 2008-02-29 00:00:00Z == 2021-02-28T00:00:00.000Z
14 calendar years since 2008-02-29 00:00:00Z == 2022-02-28T00:00:00.000Z
also:
1 calendar months since 1930-01-31 00:00:00Z == 1930-02-28T00:00:00.000Z
2 calendar months since 1930-01-31 00:00:00Z == 1930-03-31T00:00:00.000Z
3 calendar months since 1930-01-31 00:00:00Z == 1930-04-30T00:00:00.000Z
4 calendar months since 1930-01-31 00:00:00Z == 1930-05-31T00:00:00.000Z
5 calendar months since 1930-01-31 00:00:00Z == 1930-06-30T00:00:00.000Z
6 calendar months since 1930-01-31 00:00:00Z == 1930-07-31T00:00:00.000Z
7 calendar months since 1930-01-31 00:00:00Z == 1930-08-31T00:00:00.000Z
8 calendar months since 1930-01-31 00:00:00Z == 1930-09-30T00:00:00.000Z
9 calendar months since 1930-01-31 00:00:00Z == 1930-10-31T00:00:00.000Z
10 calendar months since 1930-01-31 00:00:00Z == 1930-11-30T00:00:00.000Z
11 calendar months since 1930-01-31 00:00:00Z == 1930-12-31T00:00:00.000Z
12 calendar months since 1930-01-31 00:00:00Z == 1931-01-31T00:00:00.000Z
* The udunits ref time implies missing components e.g. 1 hour since 2011-1-1
means 1 hour since 00:00 on 2001-1-1. What do missing components of ISO strings
imply in your implementation? I think it has got to imply something, because
these datetimes are still complete time specifications, aren't they.
good point, i will add a sentence saying missing fields must be set to 0.
* For further udunits compatibility, it would be convenient to be able to omit
the time zone, which would imply Z. All global model data is in UTC, I should
think, and I suppose it must be the obvious choice for all global datasets.
ok, ill add that.
I think that we should use standard_names of time for datetimes only, and other
words, such as period, for intervals of time in standard_names. Then we can
give them different sorts of units.
agree
Best wishes and thanks
thanks for the feedback!
John
_______________________________________________
CF-metadata mailing list
CF-metadata@cgd.ucar.edu
http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
