⇐ ⇒

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

From: Jonathan Gregory <j.m.gregory>
Date: Mon, 1 Jun 2015 18:02:39 +0100

Dear Jim and Chris

I know you're not comfortable with it, but you're not being asked to tell
people it's OK actually! :-) The CF convention is mostly for allowing people to
describe clearly what they've done, not tell them what to do. It is perfectly
fine, and usual, for particular projects which mandate CF to specify more
restrictive rules about what should or should not be be done. I think that
most people who encode real-world times are doing so with the no-leap-second
calendar. You are also right to point out that the timestamps they are encoding
may themselves be slightly wrong because they might have been decoded with the
no-leap-second calendar even if they were supposed to be UTC. So the situation
is unclear, as you say. This second problem applies even if the data-producer
thinks they are encoding UTC times with leap seconds. I prefer to call it
gregorian_nls because that is a way the data-producer can record what they have
done in encoding the time coordinate. At least they should know that!

Yes, I think it is fine to point out that if the calendar is gregorian_nls,
the time coordinates may be imprecise by up to a minute, say, so differences
between them should not be depended upon for high accuracy.

While not happy, would you agree to introduce gregorian_utc, gregorian_gps,
gregorian_nls, define gregorian = gregorian_nls and deprecate it? I think we
should omit gregorian_tai (although it's been instructive to discuss it) since
it's not been asked for yet.

Although I agree it could be done, I don't see why one would use gregorian_gps
before its epoch. Does anyone have a present use-case for that? If not, I don't
think it should be allowed to refer to times before the GPS epoch. If it is
needed subsequently, we can introduce proleptic_gregorian_gps then, and decide
what it means according to the use-case presented.

> >so the Calendar is ONLY for defining the reference
> >timestamp in the units.

I don't agree still with this. The calendar specifies the time system for
the reference time-stamp and the decoded time-coordinates, I have learned,
and it also specifies how the translation is done. I recognise that these
are distinct functions of it, but it's more convenient to achieve both with
one attribute, since you can't vary these aspects separately.

Best wishes

Jonathan
Received on Mon Jun 01 2015 - 11:02:39 BST

This archive was generated by hypermail 2.3.0 : Tue Sep 13 2022 - 23:02:42 BST

⇐ ⇒