Here's a table describing (most of) the different possible answers to the three questions, along with an answer to a fourth, implied question, "Do I need a leap second table to get to UTC from here?"
Metrical Elapsed Times | Alternate System | Epoch Stamp | Need Leap Seconds for UTC ---------------------- | ---------------- | ---------- | ------------------------- Yes | None | TAI | Yes Yes | None | UTC | Yes Yes | None | Uncorrected GPS | Yes Yes | None | Some other time system | Yes No | ???? | TAI | ???? No | Naively converted UTC | UTC | No No | ???? | Uncorrected GPS | ???? No | ???? | Some other time system | ???? ?? | ???? | ???? | ???? The 'Alternate System' column is for the answer to the third question. The '??' and '????' entries indicate an answer of, "I don't know". The first four entries are all for metrical elapsed time in the variable. If our primary goal is to document the time system used for the epoch time stamp, then we need two or more new calendars - one for TAI, one for UTC, one for uncorrected GPS, and maybe others that we haven't learned about yet. If the user wants to take time values in any of these cases to UTC time stamps, she will need a leap second table and software that knows how to use it. If she is happy with staying in the epoch system, she can do a naive conversion to a time stamp and it will be accurate. She may not even need to go to time stamps, in which case she is also fine. The next four entries are all for non-metrical elapsed time in the variable. There is only one case here that makes any sense, as far as we are currently aware. That is the case where UTC time stamps were naively converted to elapsed times. The user won't need a leap second table to get UTC time stamps from the contents of the time variable. If she wants to get metrical time values, she can do so with a leap second table and some custom software. From there she can do what she likes. The last case is one where the user doesn't know whether or not the time values are metrical, doesn't know for sure that time system the epoch time is in, and doesn't know what alternative method could be used. This is where __all__ of our time variables are right now. We may find out from the data producer what method they used so that we can work with the data in the way we need to, but there are no clues inside the time variable or the file. The only difference in the first four cases is the time system used for the epoch time stamp. We could go quite specific and make three new calendars for these cases. (The fourth case awaits definition of the time system.) __Or__ we could simplify here and specify that the epoch time stamp will always be UTC. This would impose a burden on users that wanted to get time stamps in the epoch time system. It's not a heavy burden for someone armed with a leap second table. I think this set of cases deserves somewhere between one and three calendars. The 'Naively converted UTC' case is the one case in the second group that has any utility. There are a lot of files out there that fall in this case. I think this deserves its own calendar. The last entry is what I think our current **`gregorian`** calendar covers now. And I think we should leave it that way. We should add verbiage to the definition of this calendar to warn users that metrical/non-metrical status is unknown and that the time system for the epoch time stamp is unknown. By the way, this case is great for the modelers and for observational data and users that don't have sub-minute accuracy requirements. So that gives us 1-4 new calendars, whatever their names might be, in addition to the classic gregorian calendar. -- 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-436052047
