Tim,
And, as I see it, CF defines your first case for time, not the alternative.
Jim
On 6/10/15 11:10 AM, Timothy Patterson wrote:
It seems to me the various choices basically come down as to whether the
producer or the user should have the responsibility of converting/interpreting
the contents of the time variable.
If time coordinate was seen as equivalent to weight or temperature, then we
would have units and a convenient offset time to keep the size of the stored
numbers manageable. This would be a simple count of time units (no gaps, leaps,
etc.). The producer would be responsible for encoding whatever
time/date/calendar they had used locally for their timestamps into these time
units for storage in the netCDF file. The user could then either use these
units, if convenient, or convert them into whatever timestamp they liked (even
something not in the CF like the Mayan calendar!).
Alternatively, the responsibility is placed on the user, by having a time unit into which a producer can dump their timestamps and add a set of attributes that explain to the end user how their particular timestamps need to be interpreted and processed. It's then up to the end-user to read the timestamps correctly and convert to a continuous time coordinate if required.
In the first case, a time variable is unambiguous and equivalent to other
measurements like weight and temperature. You can use it as a coordinate
straight from the box. In the second case, the time variable may contain one
of a variety of different encodings and will often require some assembly by the
user before use.
Regards,
Tim
-----Original Message-----
From: CF-metadata [mailto:[email protected]] On Behalf Of David
Hassell
Sent: Wednesday, June 10, 2015 4:14 PM
To: Jim Biard
Cc: [email protected]
Subject: Re: [CF-metadata] How to define time coordinate in GPS?
Hello Jim,
I'm not entirely convinced by this argument. Here is a counter example that I
have in mind:
A conversion from kilograms to carats does not alter anything, fundamentally,
in the data values. However, a change of calendar by the user could, for
example, place a value in a different year than intended by the producer, in
which case annual averages computed by the producer and the user would be
different.
What do you think?
All the best,
David
---- Original message from Jim Biard (09AM 10 Jun 15)
Date: Wed, 10 Jun 2015 09:51:21 -0400
From: Jim Biard <[email protected]>
To: [email protected]
Subject: Re: [CF-metadata] How to define time coordinate in GPS?
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0)
Gecko/20100101 Thunderbird/31.7.0
Jonathan,
I didn't see your initial statement that you reference as enforcing
anything on data consumers, or I would have raised this earlier.
Let's think about this in a simpler context. If I, as a data producer,
store values in a data variable in units of kilograms and designate it
as such with the units attribute, that doesn't mean every data
consumer should feel like they must display the values as kilograms.
They are free to select the units they prefer and, as long as they do
the conversion correctly, that is completely fine.
In a more complex and somewhat analogous case, if I as a data producer
store my geographic coordinates in latitudes and longitudes, and
properly designate the units and the reference datum that I used, data
consumers can display my data using those latitudes and longitudes, or
they can display my data using a projected coordinate system where
they have converted my latitudes and longitudes into X and Y values,
or whatever else they choose (and I hope that whatever else they might
do is valid!). What I must do as a data producer is accurately
identify the geographic Coordinate Reference System that is the basis
for my geographic coordinate values (and then make sure that my
coordinate values are correct if I started in some different CRS).
A properly formed time variable needs to have contents that are metric
(by that I mean that you can do differencing math with the values),
and if it contains real-world time observations it needs to be
anchored to a recognizable point in history. The system we have in
place using elapsed time values with a reference epoch does just that.
The decision about how to represent the time values as timestamps for
display purposes should be left up to the data consumer. You may have
used a reference epoch expressed using the Proleptic Gregorian
calendar, but if I would rather express timestamps on my plots using
the Julian calendar, that's my business. Perhaps the discipline I am
working in has a convention of using Modified Julian Days, so I am
going to convert everything to days since 1858-11-17 00:00:00.
Whatever my choice of output form for times, it is crucial that I know
where the elapsed time values stored in my time variable are anchored
in history, and that is what we should be trying to make clear with
the units and calendar attributes (and any other time-related
attributes that might arise).
Grace and peace,
Jim
On 6/9/15 1:21 PM, Jonathan Gregory wrote:
Dear Jim
You wrote
The calendar only specifies how the reference date and time are to
be interpreted. It says nothing about either the time variable
values or the decoding that should be used to turn those elapsed
time values into dates and times. That choice is entirely up to the
data consumer. If a data producer started with a set of Julian
calendar dates and created a time variable, and a data user prefers
to use Proleptic Gregorian dates, there is no problem. One is not
more correct than the other.
You are right to point to this as a point of disagreement. I thought
we had discussed this earlier e.g. in
http://mailman.cgd.ucar.edu/pipermail/cf-metadata/2015/058224.html
I wrote
Clarify that in the CF convention the choice of "calendar" implies
the particular set of rules that is used to convert between
date-times (YYYY-MM-DD hh:mm:ss i.e. sets of six numbers) and time
coordinates in units of elapsed time since a reference time.
and I believe that this arose from an earlier discussion about this
being a CF-specific use of the term "calendar". Maybe I have misunderstood you
now.
I think the data producer is the person who decides what the data
means. If the producer has Julian calendar timestamps and encodes
with Julian rules as a time coordinate variable, the data-user is
wrong to decode them with any other rules into timestamps or
interpret them as being in any other calendar. Why would that be a
useful thing to do? I agree with your earlier posting and email that
there is a range of timestamps which refer to the same points in time
in the Gregorian and Julian calendars (long ago, before they drifted
apart) so for that range of dates it would not matter if the data-
user changed the calendar, since they're indistinguishable. But that
is a special case. If you come up to present, a given time-stamp
refers to a different instance in time in the Gregorian and Julian
calendars, just like it does between UTC and GPS calendars. For model
calendars, it would be nonsense for time coordinates encoded in the 360-day
calendar to be decoded in the proleptic Gregorian calendar, for example.
Perhaps we view time coordinates in different ways? I think the
timestamps are the primary information, and the time coordinates are an encoded
version.
We do it like that for efficiency of storage, and convenience and
robustness of processing, since string-valued timestamps are
relatively awkward. It has also the great advantage that the encoded
time coordinate is also an elapsed time variable, so it can be used to check
monotonicity and for calculations.
This is a common need, since time is a continuous coordinate.
Best wishes
Jonathan
_______________________________________________
CF-metadata mailing list
[email protected]
http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
--
CICS-NC <http://www.cicsnc.org/> Visit us on
Facebook <http://www.facebook.com/cicsnc> *Jim Biard*
*Research Scholar*
Cooperative Institute for Climate and Satellites NC
<http://cicsnc.org/> North Carolina State University
<http://ncsu.edu/> NOAA National Centers for Environmental Information
<http://ncdc.noaa.gov/> /formerly NOAA’s National Climatic Data
Center/
151 Patton Ave, Asheville, NC 28801
e: [email protected] <mailto:[email protected]>
o: +1 828 271 4900
/Connect with us on Facebook for climate
<https://www.facebook.com/NOAANCEIclimate> and ocean and geophysics
<https://www.facebook.com/NOAANCEIoceangeo> information, and follow us
on Twitter at @NOAANCEIclimate <https://twitter.com/NOAANCEIclimate>
and @NOAANCEIocngeo <https://twitter.com/NOAANCEIocngeo>. /
_______________________________________________
CF-metadata mailing list
[email protected]
http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
--
David Hassell
National Centre for Atmospheric Science (NCAS) Department of Meteorology,
University of Reading, Earley Gate, PO Box 243, Reading RG6 6BB, U.K.
Tel : +44 118 3785613
E-mail: [email protected]
_______________________________________________
CF-metadata mailing list
[email protected]
http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
Any email message from EUMETSAT is sent in good faith but shall neither be
binding nor construed as constituting a commitment by EUMETSAT, except where
provided for in a written agreement or contract or if explicitly stated in the
email. Please note that any views or opinions presented in this email are
solely those of the sender and do not necessarily represent those of EUMETSAT.
This message and any attachments are intended for the sole use of the
addressee(s) and may contain confidential and privileged information. Any
unauthorised use, disclosure, dissemination or distribution (in whole or in
part) of its contents is not permitted. If you received this message in error,
please notify the sender and delete it from your system.
_______________________________________________
CF-metadata mailing list
[email protected]
http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
--
CICS-NC <http://www.cicsnc.org/> Visit us on
Facebook <http://www.facebook.com/cicsnc> *Jim Biard*
*Research Scholar*
Cooperative Institute for Climate and Satellites NC <http://cicsnc.org/>
North Carolina State University <http://ncsu.edu/>
NOAA National Centers for Environmental Information <http://ncdc.noaa.gov/>
/formerly NOAA’s National Climatic Data Center/
151 Patton Ave, Asheville, NC 28801
e: [email protected] <mailto:[email protected]>
o: +1 828 271 4900
/Connect with us on Facebook for climate
<https://www.facebook.com/NOAANCEIclimate> and ocean and geophysics
<https://www.facebook.com/NOAANCEIoceangeo> information, and follow us
on Twitter at @NOAANCEIclimate <https://twitter.com/NOAANCEIclimate> and
@NOAANCEIocngeo <https://twitter.com/NOAANCEIocngeo>. /
_______________________________________________
CF-metadata mailing list
[email protected]
http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
