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
CF-metadata at cgd.ucar.edu
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.
Received on Fri Jun 12 2015 - 04:12:29 BST
