................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)?
Also that the calendar attribute would be applicable to the full units
attribute - base date and base time and time increment.
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?
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?
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
