[CF-metadata] How to define time coordinate in GPS?

From: Jonathan Gregory <j.m.gregory>
Date: Wed, 13 May 2015 17:54:26 +0100

Dear Jim

I think your last email (which didn't go to the email list) explains why we
have not been understanding each other about your points 2 and 3:

> There shouldn't be (or there is no) good reason to use a different
> calendar to encode and decode, but this is exactly what has been
> done with regard to times. As a netCDF file producer, if you have a
> set of observations that have attached correct Gregorian/UTC date &
> time strings and you use a POSIX calculator to encode your times
> since your correct Gregorian/UTC reference date & time string, then
> you are at risk of producing incorrect elapsed time values. (Whether
> you actually do or not depends on factors mentioned in previous
> emails.) The contents of time variables *should* always be true
> counts of time that has elapsed since the reference epoch and
> *should* never, ever encode leap second induced discontinuities or
> offsets.

That's not how I understand what we've been discussing. I think that if
calendar="gregorian[_nls]" then the encoding/decoding should be done without
leap seconds (86400 s per day), but if calendar="gregorian_utc" the encoding/
decoding should be done with leap seconds according to UTC. This why I see
the issue as being one that relates to the calendar, and not to the units
or the reference time, which are calendar-neutral. Is this what we disagree on?

I can see there's a difficulty with the UTC calendar that if a second is taken
out there will be two consecutive seconds with the same timestamp. This is
a problem for encoding - the data-writer would have to be careful that he
chose the right one. It's not a problem for using the encoded time coords,
which will be monotonic and run forward at 1 second per second, nor for
decoding, which will correctly produce the repeated timestamp. Inserting a
leap second is the same kind of discontinuity as the change from Julian to
Gregorian calendar. It means that there is a range of date-times which cannot
be encoded because they are not valid, but decoding is no problem. Similarly
there are dates which are valid in some calendars but not others, such as
30 Feb being valid in the 360_day calendar.

I think my view is consistent with the general treatment of calendars by CF.
The encoding/decoding algorithm differs, but the same units string could
always be used.

Best wishes

Jonathan
Received on Wed May 13 2015 - 10:54:26 BST