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
> CF-metadata at cgd.ucar.edu
> 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: jbiard at cicsnc.org <mailto:jbiard at cicsnc.org>
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 _at_NOAANCEIclimate <https://twitter.com/NOAANCEIclimate> and
_at_NOAANCEIocngeo <https://twitter.com/NOAANCEIocngeo>. /
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.cgd.ucar.edu/pipermail/cf-metadata/attachments/20150601/fcf68233/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: CicsLogoTiny.png
Type: image/png
Size: 15784 bytes
Desc: not available
URL: <http://mailman.cgd.ucar.edu/pipermail/cf-metadata/attachments/20150601/fcf68233/attachment-0001.png>
Received on Mon Jun 01 2015 - 14:39:28 BST
