Dear Jim
> I am good with having the three. I'd like to indulge in one small
> anticipation and add gregorian_tai, which is like GPS but has an
> epoch date of 1958-01-01, so it's now 36 seconds different from UTC.
> This is the "atomic clock" time system.
I agree it would be easy and obvious to include this as well. I'm not sure
whether we should do so before someone says they need it.
> There's one last question I have about all of this, and that has to
> do with proleptic times in each system. UTC was established around
> 1960, so I think that for dates prior to that we need to either say
> that UTC is assumed to match the GMT system that it replaced, or say
> that the plain gregorian calendar should be used. Since they don't
> have leap seconds, correct GPS and TAI times prior to their epoch
> dates could, on the other hand, be derived from accurate elapsed
> time measurements.
>
> No matter which way you handle it, exact conversions between UTC and
> the other time systems prior to the UTC epoch date are likely
> difficult and may be impossible. It's also true that there are, by
> definition, no true GPS or TAI times prior to their epoch dates.
I'm glad you asked about this. I think that gregorian_utc should be proleptic,
meaning that it is the same as gregorian before the UTC epoch. This is the
usual "real world" time system, and there are many observational needs for a
a continuous time coordinate that crosses the UTC epoch. Your sentence implies
that gregorian is different from "the GMT system". What is that difference?
I am not sure that gregorian_gps should be proleptic. Is there a use-case for
a time coordinate which is specifically GPS time that crosses the GPS epoch?
If so, what time system was used before GPS in that case? A minimal approach
would be to disallow gregorian_gps reference times or decoded times that are
earlier than the GPS epoch. I understand "gregorian" in "gregorian_gps" to
refer to the days-month-years rules of the calendar, but maybe this restrictive
approach would actually be calendar="gps", not calendar="gregorian_gps".
Best wishes
Jonathan
>
> What are your thoughts?
>
> Grace and peace,
>
> Jim
>
> On 7/15/15 4:34 AM, Jonathan Gregory wrote:
> >PS. First, to repeat myself:
> >
> >So my conclusion (at present - but I suspect I haven't understood something
> >you have said) is that gregorian is fine and sufficient (with the addition of
> >gregorian_utc and gregorian_gps for the well-defined real-world systems) if
> >we define it to mean that 86400-seconds are assumed to be used for conversion
> >from clock time to elapsed time and elapsed time to clock time, that it is not
> >defined whether the reference time and clock times are GPS and UTC, and that
> >the elapsed times may not be exactly correct for the real world (due to the
> >neglect of leap seconds).
> >
> >I also said, "This is then the same as gregorian_utc_nls, so we would not need
> >that either, which was your final conclusion in your previous post." Actually
> >it's not quite the same as gregorian_utc_nls, which asserts that clock times,
> >if real-world, are UTC. Otherwise it's the same. If my conclusion above is
> >correct, then I don't mind whether we introduce gregorian_utc_nls or not. No-
> >one has definitely asked for it, as far as I remember; we discussed it because
> >of anticipating the need, I believe. We could therefore follow the usual CF
> >principle of omitting it until it's asked for.
> >
> >Cheers
> >
> >Jonathan
> >
> >----- Forwarded message from Jonathan Gregory <j.m.gregory at reading.ac.uk-----
> >
> >Date: Wed, 15 Jul 2015 08:01:04 +0100
> >From: Jonathan Gregory <j.m.gregory at reading.ac.uk>
> >To: cf-metadata at cgd.ucar.edu
> >Subject: [CF-metadata] How to define time coordinate in GPS?
> >User-Agent: Mutt/1.5.21 (2010-09-15)
> >
> >Dear Karl
> >
> >I think the meaning of "gregorian" up to CF 1.6 is actually not clear, because
> >we had not thought about these distinctions earlier. If we change the calendar
> >definitions, it does not affect the interpretation of any existing data written
> >with previous versions. However I agree that it would be inconvenient for data-
> >users if they had to process "gregorian" times differently according to the
> >setting of the Conventions version.
> >
> >I thought that the current proposal was that gregorian would be vague in
> >future, like you wrote in your second option:
> >
> >1) might or might not account for leap seconds, 2) might or might not assume
> >the length of the solar day is exactly 86400 seconds long, and 3) might express
> >the reference time according to either UTC or GPS
> >
> >and that is exactly the reason why, after agreeing with Jim last week, I
> >changed my mind to argue that we needed gregorian_nls for model data, to
> >preserve the exactness for times which really are always 86400-second days.
> >You agree we would need gregorian_nls in that case. I agree that it means that
> >models would use gregorian_nls in future, not gregorian.
> >
> >However in your first option you don't think this is necessary:
> >
> >Under the "gregorian" calendar the length of the solar day can be assumed to be
> >exactly 86400 seconds long (i.e., there are no leap seconds). This means that
> >for models where this assumption almost invariably is valid, conversion from
> >elapsed time to clock time is straight-forward and exact, whereas for
> >observations, conversion to clock time may introduce errors as large as 16
> >seconds because it is unknown whether the UTC or GPS time system has been used
> >in specifying the reference times (appearing in the time units attribute), and
> >it is also unknown whether leap seconds have been properly accounted for in
> >converting UTC clock times to elapsed time.
> >
> >I'm sorry, but I can't see what is the difference. In both cases you say it
> >is unknown whether leap seconds have been included in converting from clock
> >time to elapsed time. Is the crucial difference about the length of the day?
> >Does "assume the solar day to be exactly 86400 seconds" mean "assume all days
> >are 86400 seconds in converting elapsed time to clock time"?
> >
> >If that's what you mean, I think your first and preferred option is fine, and
> >then I agree we do not need gregorian_nls. To spell it out, I think this is
> >acceptable if "gregorian" means that you will recover the clock times (time-
> >stamps) exactly by using an algorithm that assumes constant 86400-second days
> >(i.e. with no leap seconds). If these clock times refer to the real world, it
> >is undefined whether the reference time is GPS or UTC, and consequently it is
> >undefined whether the decoded clock times are GPS or UTC.
> >
> >But my statement "you will recover the clock times (time-stamps) exactly by
> >using an algorithm that assumes constant 86400-second days" is inconsistent
> >with your statement "conversion to clock time may introduce errors ... because
> >it is unknown whether ... leap seconds have been properly accounted for in
> >converting UTC clock times to elapsed time". According to my statement,
> >gregorian means that leap seconds were ignored when converting clock times to
> >elapsed times i.e. 86400-second days were used. If that's not the case, you
> >can't decode accurately. Thus the elapsed times may not be quite right for the
> >real world. This is then the same as gregorian_utc_nls, so we would not need
> >that either, which was your final conclusion in your previous post.
> >
> >So my conclusion (at present - but I suspect I haven't understood something
> >you have said) is that gregorian is fine and sufficient (with the addition of
> >gregorian_utc and gregorian_gps for the well-defined real-world systems) if
> >we define it to mean that 86400-seconds are assumed to be used for conversion
> >from clock time to elapsed time and elapsed time to clock time, that it is not
> >defined whether the reference time and clock times are GPS and UTC, and that
> >the elapsed times may not be exactly correct for the real world (due to the
> >neglect of leap seconds).
> >
> >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>. /
>
>
> _______________________________________________
> CF-metadata mailing list
> CF-metadata at cgd.ucar.edu
> http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
----- End forwarded message -----
Received on Wed Jul 15 2015 - 10:19:01 BST
