Jonathan,
On 6/11/15 11:09 AM, Jonathan Gregory wrote:
Dear Jim
I appreciate your willingness to continue this attempt to find a
meeting of the minds about all of this. I hope you will forgive me
if I am not always completely clear in my attempts to express myself
or fail to understand you.
I would say exactly the same to you! Thanks. Actually I'm struggling to
understand what we are disagreeing about.
As a data consumer, all I have to do is convert the reference time
from the stated calendar to my desired calender, then use that as
the basis for producing timestamps from the elapsed times in the
variable (using the correct set of time functions, of course).
Expressing the elapsed times as timestamps in one calendar and then
converting those timestamps to another is another way that you could
do it, but one which adds unneeded steps.
In both our views, decoding the time coord (into components of time, which
I will refer to as "timestamps" for convenience although we would probably not
use strings for this purpose, since usually we want numbers) according to the
calendar stated by the attribute requires using the algorithm appropriate for
the calendar. This algorithm is one which can add an offset to the reference
timestamp using the rules of the calendar to produce new timestamps, and the
reverse. Hence the calendar attribute implies particular rules for encoding and
decoding. But that is the statement of mine which you disagree with, I think -
isn't it?
I agree with what you said above up until your last sentence. The
definition of a calendar includes (by implication) the rules for how to
convert between an elapsed time count since a reference epoch and a
timestamp as expressed in that calendar. I don't see the calendar
attribute as implying a particular set of rules to follow for the entire
contents of a time variable (see below).
I agree that the calendar attribute also states the calendar in which the ref
time is expressed - this second function is one I have recognised because of
our discussion (it is obvious in the case of model calendars, so I didn't see
it as a distinct function). Since the att states the calendar of the ref time,
and implies the rules for encoding and decoding, it therefore also inevitably
implies the calendar of the decoded timestamps, doesn't it?
This is where we start diverging more significantly. As I see it, the
calendar attribute specifies "the calendar in which the ref time is
expressed", and nothing more. If the data producer has done her job
correctly the elapsed time values are metric measures relative to an
epoch point in the units (seconds, minutes, hours, days, etc) specified
in the units attribute, and are calendar neutral. I might have started
with timestamps in the calendar named in the calendar attribute, but I
might also have started with a start timestamp and stopwatch readings.
My start timestamp might not have been in the calendar that I named in
the calendar attribute, but as long as I converted the timestamp from
the original calendar to the one named in the calendar attribute, it
doesn't matter. This assumes, of course, that such a conversion is
possible, as I mentioned in my last email.
I agree that you could change to a new calendar in the real world by
calculating the difference in seconds between the ref time if it's interpreted
in the old calendar and if it's interpreted in the new calendar (or a new
ref time if you want to change the ref time as well as the calendar) and then
adjusting the time coordinates by this amount (and the ref time in the units
string if you want to change that as well). I think that will be the same as
what I suggested, which is to decode the coords using the old calendar and
ref time, then encode them using the new calendar and ref time. Perhaps my
method sounds like more calculation, but it might be easier to carry out (just
two subroutine calls). I think these methods are equivalent, aren't they?
Assuming that you can change to the new calendar, all you have to do is
make one call to a function that converts a timestamp from one calendar
to another, then use the converted timestamp in your decoding function
appropriate to the new calendar. There are a variety of ways to go about
it, but the point is that the necessary and sufficient condition for the
change is converting the reference timestamp from the one calendar to
the other. If a valid conversion exists, and if you do it the one time,
no other reference to the calendar named in the attribute is required.
They work because, as we agree, the encoded time coord is also an elapsed time,
and is useful as such. The only situation in which it might have small dis-
continuities is if the no-leap-second algorithm is used to encode and decode
UTC and, as we have agreed, there should be a clear warning against not doing
that if precision <1 min is required.
Correct. This amounts to an error on the part of the data producer or
time measurer. Actually, half correct. If the wrong algorithm was used
to encode (create the elapsed times), then the contents of the time
variable potentially contain discontinuities and/or offsets (as we have
covered in previous emails). If the data consumer manages to decode
using the inverse algorithm to the one used by the data producer, then
you won't see the errors in the timestamps produced.
The reason that I regard timestamps as primary, and therefore suggest that one
would go via timestamps to change the calendar, is because of the non-real-
world calendars that are the subject of other emails. Although, as you rightly
say, there is no exact way to draw an equivalence between the real-world
and the various non-real-world calendars (360_day, no_leap, etc.), we have to
draw such an equivalence for model-model and model-obs comparisons. The main
purpose of CF is to clarify when and how data is to be regarded as comparable,
and it's a common need to compare climate data in different calendars. When
this is done, it's the timestamps which are comparable. DJF (season) is DJF
(including all of Dec, Jan and Feb) whichever calendar is used, even though it
has different lengths in those calendars. Therefore it is the timestamps which
truly define the ranges of time, not the relative time coordinates.
In truth, the time in a non-real-world calendar is not comparable to
time in a real-world calendar. There is no conversion path. You
certainly are free to match timestamps when doing comparisons between
model data and observations. But there is no conversion between
calendars going on when you do that. You are making a calculated
decision to compare quinces and apples, being fully aware of why you are
doing it.
Matching timestamps without conversion is exactly what you would *not*
want to do when comparing observations recorded using two different
real-world calendars. If one set of timestamps used the Julian calendar,
and the other used the Gregorian calendar, you would not want to compare
the observations for April 1, 2015 in both calendars. In this case, you
either convert one set of times from one calendar to the other, or find
the offset between the reference timestamps. Once you have the offset,
you could compare observations based on undecoded elapsed times if you
wanted to.
So, as I see it, timestamps are not primary. The reference timestamps
defined by their calendars and the metric elapsed times are primary. If
you have these and a conversion exists between two calendars, you have
all you need to do it. If no conversion exists you must resort to some
form of approximation, but that's your business as a data consumer.
Best wishes
Jonathan
_______________________________________________
CF-metadata mailing list
[email protected]
http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
Grace and peace,
Jim
--
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
