Tim,
On 6/11/15 12:00 PM, Timothy Patterson wrote:
................Jim's Suggested Update...............
4.4.1 Calendar
In order to know what point in history has been measured by a given base date,
base time, and time increment, one must know what calendar was used for the
base date and time. The calendar attribute defines the particular date and time
system that was used to express the reference time string found in the units
attribute, and is assigned to the time coordinate variable. The values
currently defined for calendar are:
...............................................
Although they aren't explicitly defined above, am I right to assume that using
the standard units convention for time;
time:units = "days since 1990-1-1 0:0:0" ;
the base date and base time correspond to the date/time string after the word "since"
(1990-1-1 0:0:0) and the time increment corresponds to the units before the word "since"
(days)?
Good question! I had assumed that the 'time increment' corresponded to
an elapsed time value stored in the time variable, which is in the units
declared in the 'before the word "since"' part of the units attribute.
This should be reworded to make it clearer (whichever is meant).
Also that the calendar attribute would be applicable to the full units
attribute - base date and base time and time increment.
To my way of thinking, the calendar attribute only applies to the base
date and time. The measurement units (second, minute, hour, day, etc)
are defined separately.
Doesn't this conflict with the current convention in Section 4.4 where it is
strongly implied that the base date and time are always supplied as UTC times?
We have agreed that we need to rewrite section 4.4 to remove
specification of UTC.
Also, in Jonathan's last email he writes " 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."
We are trying to use the CF conventions for instrument data and in this case, we're looking for
much greater precision than 1 minute so the difference between an encoded "timestamp"
and an encoded "elapsed time" is important in our case.
Taking the suggested modified text at the start, would I be right in saying that the calendar
modifier is also intended to modify the units. So applying a UTC calendar to "seconds since
1990-1-1 0:0:0" is in effect modifying the units to be "utc_seconds since 1990-1-1
0:0:0", meaning that this is counted on a discontinuous UTC time scale and not a continuous
elapsed seconds time scale.
If my interpretation is correct, then this would remove the possibility of
being able to specify a point in time in UTC and then have a true elapsed count
(i.e. continuous rather than with UTC leap second gaps) since that time. Some
of our products are currently using this method to compact the time data. By
counting up from a recent event (i.e. the start of a scan line) rather than the
start of year 2000 we can encode the data as a ushort of milliseconds instead
of a double of seconds. The timestamp of the start of the scan line is
expressed as a UTC (according to my understanding of the current conventions)
and the units as milliseconds.
e.g. time:units = "milliseconds since 2015-06-11 17:51:22" ;
We then work in relative times as we 're not interested in expressing these time values
as a calendar "timestamp".
Does this still work under the proposed scheme?
My position is that there are no 'UTC seconds'. There are only SI
seconds. The elapsed times in a time variable should never contain
discontinuities. In the proposed scheme, or even in the current scheme,
you should always be able to work correctly in relative times. In the
current scheme the time system used for the base time is effectively
defined as UTC. As long as you correctly represent your base date and
time using the Gregorian calendar and UTC time system, and correctly
count your elapsed times, your time variable is correctly formed. (If
your base date and time were originally provided as TAI time or
something else besides UTC time, you would need to correctly convert
your original base date and time to UTC.)
One of my goals in the discussion we have been having is to make sure
that we don't define time and calendars such that it's considered OK to
encode discontinuities into the elapsed times in time variables.
Jonathan's mention of encoding discontinuities is part of the
acknowledged reality that people may well have started with UTC
timestamps and used POSIX time conversion functions to them into elapsed
times because they weren't aware of the pitfalls. If your time
resolution is large in comparison to the possible errors introduced by
doing so, then this error is effectively ignorable. In your case, such
an error can be significant.
The new scheme involves refining our definitions and adding calendars
that include definitions of the time system used (UTC, GPS, TAI, etc) in
addition to the date system used (Gregorian, etc). I don't want any of
them to state or imply that it's OK to introduce discontinuities into
the elapsed times stored in the variables.
Regards,
Tim
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
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
