Hi all:
IMO, the problem stems from confusing datetime "2012-02-27T00:00:00Z" which
is not a unit, with time "secs", which is [1].Then, use a units package
like udunits to define datetime.
The problem is that it works most of the time, since in the common case of
"real" time, datetime can be expressed as a time offset, and you can easily
form differences and manipulate them in udunits.
As Nan points out, this does not work for climatological times like
"months", and leads to confusion. In this case the "time" coordinate is
more than just a label, but not expressible as a fixed number of seconds
from a base date.
The CDM uses an extension of udunits syntax, eg "3 calendar months since
2012-02-27T00:00:00Z", which I think is a reasonable solution [2], in the
sense that its easy to implement, is a superset of udunits, and satisfies
known use cases.
John
[1]
https://en.wikipedia.org/wiki/Units_of_measurement
[2]
http://www.unidata.ucar.edu/software/thredds/current/netcdf-java/CDM/CalendarDateTime.html
On Thu, Sep 17, 2015 at 7:54 AM, Nan Galbraith <ngalbraith at whoi.edu> wrote:
>
> Hi Jim -
>
> The problem isn't human-readability, though. The problem is that when you
> generate a file that has, say, the mean temperature for each month,
sometimes
> over a period of years, there are no 'days' in the process. Any data that
represents
> February goes into the February bin, whether 28 or 29 days; although
March is always
> 31 days long, its mid-point is a different number of 'days since' the
beginning of
> the year.
>
> In the case of the file Ajay presented, time is a singleton, and its
value represents
> the center point of the first 3 months of the years 1955-2012. That can't
be accurately
> expressed as a number of days, only as months.
>
> Is there a trac ticket for climatology data? If not, do we need one?
>
> Cheers - Nan
>
>
> On 9/17/15 9:32 AM, Jim Biard wrote:
>
> Nan,
>
> The problem is, udunits defines a month as having a specific length of
year/12 = 30.44 days, so if you use udunits to convert to anything else,
you won't end up where you think you will. The better practice is to use
days. It's not as "human readable", but it's the only way to do proper
conversions between time bases.
>
> Grace and peace,
>
> Jim
>
> On 9/17/15 9:06 AM, Nan Galbraith wrote:
>
> While it's true that 'month is not a proper unit of measure',
> climatologies do in fact use months, not days, in calculating
> mean values. Adhering to udunits/CF in this regard could make
> the dates less easily understood.
>
> Regards - Nan
>
> On 9/11/15 1:34 PM, Karl Taylor wrote:
>
> Dear Ajay,
>
> Since "month" is not a proper unit of measure, convert your times to days
and use a unit "days since ...".
>
> Also, it is normally a bad idea to have your base time set to a date
before the switch from Julian to Gregorian calendar. I suggest using a base
time of "1955-01-01" (i.e., the beginning of your climatological period).
>
> I think the cell_methods should be:
> cell_methods="area: mean depth: mean time: mean within years time: mean
over years";
>
> The time bounds should be (expressed in date/time format):
>
> climatology_bounds = "1955-01-01", "2012-04-01"
>
> and you can choose your time coordinate value as you think most
appropriate, e.g.,
> the middle of the season of the first year of the climatology, or
> the beginning of the first month of the first year of the climatology, or
> the middle of the season of the middle year of the climatology, or
>
> ???
>
>
> Hope someone confirms this, as sometimes I make a mistakes.
>
> Karl
>
>
>
>
> On 9/11/15 9:54 AM, Ajay Krishnan - NOAA Affiliate wrote:
>
> Dear CF members,
>
> I would like your input on the way climatological stats are being
represented in a file that I am working on. I believe that I am not using
the time and the climatological_bounds properly:
>
> Seasonal SST
>
> Average seasonal temperature (Jan-Mar) for 6 decades (1955-2012)
>
> dimensions:
> time=1;
> nv=2;
> variables:
>
>
> double time(time);
> time:climatology="climatology_bounds";
> time:units="months since 0000-01-01";
> double climatology_bounds(time,nv);
>
>
> double climatology_bounds(time,nv);
>
> climatology_bounds:comment=? This variable defines the bounds of the
climatological time period for each time? ;
>
> float t_mn(time,lat,lon,depth);
> t_mn:standard_name: ?sea_water_temperature? ;
>
> t_mn:long_name: ?Average of all unflagged interpolated values at each
standard depth level for sea_water_temperature in each grid-square which
contain at least one measurement.? ;
>
> t_mn:cell_methods: ?area: mean depth: mean time: mean? ;
>
>
> data: // time coordinates translated to date/time format
> time= ?1.5? ;
>
> climatology_bounds=?0.0?, ?3.0? ;
>
>
> The CF examples are helpful but my case is different where in I have just
1-time co-ordinate in my file. In the above case, what is the best way to
record time and climatology bounds?
>
>
> Thanks,
>
> Ajay
>
>
>
>
> --
> *******************************************************
> * Nan Galbraith Information Systems Specialist *
> * Upper Ocean Processes Group Mail Stop 29 *
> * Woods Hole Oceanographic Institution *
> * Woods Hole, MA 02543 (508) 289-2444 *
> *******************************************************
>
>
>
> _______________________________________________
> CF-metadata mailing list
> CF-metadata at cgd.ucar.edu
> http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <
http://mailman.cgd.ucar.edu/pipermail/cf-metadata/attachments/20150917/db893e78/attachment.html>
Received on Thu Sep 17 2015 - 09:37:44 BST
