@JonathanGregory @martinjuckes @ChrisBarker-NOAA The "uncorrected GPS" time I mentioned comes from the fact that you can, by various means, obtain GPS time that is, like TAI, without leap second alterations. The native GPS time system is based on a count of SI weeks and a count of SI seconds in the week. If you have a sufficiently accessible GPS unit, you can get a YYYY-MM-DD HH:MM:SS.mmmmmm reading that doesn't have any leap seconds, or you can do a naive conversion of the weeks and seconds into a time stamp.
You can see the four most common time clocks UTC, GPS, LORAN, and TAI advancing together at http://leapsecond.com/java/gpsclock.htm If we head in the direction Jonathan summarized, then I think we need at least 3 new calendars. For time variables containing metrical elapsed times: - TAI - epoch time stamp is in TAI. Elapsed time values are metrical SI seconds. - UTC - epoch time stamp is in UTC. Elapsed time values are in metrical SI seconds. - ? GPS - epoch time stamp is in GPS. Elapsed time values are in metrical SI seconds. - ? LORAN - epoch time stamp is in LORAN. Elapsed time values are in metrical SI seconds. (The original discussion about all this back a number of years ago came from people that wanted to know how to annotate their "GPS time". I don't know if we have any LORAN time out there in our current world.) Notice that the only difference between the four calendars above is the epoch time stamp. If the four recorded the same event relative to a common epoch time, they would all have the same elapsed time value with slightly different epoch time stamps. This feels like a lot of redundancy to me. I think we then need a new calendar name for, as Jonathan put it, "converting UTC timestamps to time coordinates and back without leap seconds (naively)." The reason for a new name for this calendar is explained by my thoughts about the "old" **`gregorian`** calendar. And I think we should keep **`gregorian`** for backwards compatibility to mark time variables that have an __unknown__ relationship to metrical elapsed time. I don't like the idea of adding the implication of non-metrical elapsed time to the **`gregorian`** calendar that has been used up to now. There are a large number of observational cases where the time resolution is low enough that sub-minute shifts or offsets are irrelevant. There are a large number of built datasets where exact nature of the elapsed times in the time variables is unknown. When the modeling community uses a Gregorian calendar, they store metrical model time without leap seconds. I doubt any anyone in the modeling community is using leap seconds. For all these cases, I think it is a positive benefit to have a **`gregorian`** calendar that has an added warning about there being an unknown relationship between the time variables using this calendar and observational time systems such as TAI and UTC. -- You are receiving this because you commented. Reply to this email directly or view it on GitHub: https://github.com/cf-convention/cf-conventions/issues/148#issuecomment-436295154
