Jonathan,
Let's back down to a case where we are talking in units of whole solar
days, and all we have is a Proleptic Gregorian calendar and a Julian
calendar. No leap seconds ever get involved.
If I record the same set of dates in two different time variables, one
using the Proleptic Gregorian calendar, and one using the Julian
calendar, each using the same point in "absolute time" and representing
it correctly for its calendar, would you expect there to be any
difference in the elapsed day values in the two variables? That is, I
have a file with two variables,
dimensions:
time = 663294 ;
variables:
int t_julian(time) ;
calendar = "julian" ;
units = "days since 200-03-01" ;
long_name = "Count of Julian days" ;
int t_progregorian(time) ;
calendar = "proleptic gregorian" ;
units = "days since 200-03-01" ;
long_name = "Count of Proleptic Gregorian days";
data:
t_julian = 0, 1, 2, ... ;
t_progregorian = 0, 1, 2, ... ;
(The two calendars match from Mar 1, 200 until Feb 28, 300.)
What differences will there be between the contents of the two variables?
Grace and peace,
Jim
On 6/1/15 1:02 PM, Jonathan Gregory wrote:
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
_______________________________________________
CF-metadata mailing list
[email protected]
http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
--
CICS-NC <http://www.cicsnc.org/> Visit us on
Facebook <http://www.facebook.com/cicsnc> *Jim Biard*
*Research Scholar*
Cooperative Institute for Climate and Satellites NC <http://cicsnc.org/>
North Carolina State University <http://ncsu.edu/>
NOAA National Centers for Environmental Information <http://ncdc.noaa.gov/>
/formerly NOAA’s National Climatic Data Center/
151 Patton Ave, Asheville, NC 28801
e: [email protected] <mailto:[email protected]>
o: +1 828 271 4900
/Connect with us on Facebook for climate
<https://www.facebook.com/NOAANCEIclimate> and ocean and geophysics
<https://www.facebook.com/NOAANCEIoceangeo> information, and follow us
on Twitter at @NOAANCEIclimate <https://twitter.com/NOAANCEIclimate> and
@NOAANCEIocngeo <https://twitter.com/NOAANCEIocngeo>. /
_______________________________________________
CF-metadata mailing list
[email protected]
http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
