Thanks for the explanations, Jim.
I may be totally wrong here, but (if there were no need for backwards
compatibility) it seems to me that the convention for the standard "time"
variable could make use of constructs that are used elsewhere in the convention.
The time variable contains a count of seconds since a given base point in time.
This base point could be defined as a scalar coordinate variable i.e. I'm
measuring elapsed time and this coordinate is the point in time at which I'm
measuring elapsed time.
Also, the mapping of the elapsed time to calendar-dependent timestamps seems
somewhat analogous to the use of the grid_mapping attribute used to convert
coordinate variables to lat/lon. In this case, there could be a
"calendar_mapping" variable which would have attributes that defined the
calendar used by the producer and would allow the user to convert the elapsed
time to timestamps in the calendar.
Regards,
Tim
----------------------------------
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
--
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
