@ChrisBarker-NOAA I love your name proposals! I think your proposal to allow binary time stamps is a good one. Or even string time stamps. It could have a standard name of **`time_stamp`**. For example, if you organize a binary time stamp in 4-bit fields (which can be marked up using **`flag_masks`** and **`flag_meanings`** attributes) in high-to-low bit order YYYY-MM-DD-HH-mm-ssss where ssss represents centiseconds, you have a monotonic result.
I will say, however, that we have this large user base in the wild that isn't working this way. Even if we added this as an option, I feel like we need to give recognition to the existing use case. Regarding TAI time, there are two different potential situations, and we need to make sure we aren't confusing them. I think that confusion is my fault. There is fully metric elapsed time, which can be constructed any number of ways, among them being: - Get TAI time counts and subtract them from an epoch TAI time count. The epoch TAI time count must be converted into a time stamp for use in the **`units`** attribute. That time stamp could be TAI or UTC. - Get TAI time stamps and convert them to elapsed times since a TAI epoch. In this case, the conversion is done without consideration of leap seconds and produces correct results. The TAI time stamp could be used directly in the **`units`** attribute or first converted to UTC. - Get UTC time stamps and convert them to elapsed times since a UTC epoch. In this case the conversion is done __with__ consideration of leap seconds and produces correct results. The UTC time stamp could be used directly in the **`units`** attribute or first converted to TAI. - Get GPS week number and elapsed time counts and convert them to elapsed times since an epoch week number and elapsed time count. The epoch week number and elapsed time count must be converted into a time stamp for use in the **`units`** attribute. That time stamp could be TAI or UTC. Then there is TAI time itself. Which is, at core, a count of seconds since 1958-01-01 00:0:00. It is represented for human benefit as time stamps using the Gregorian calendar as years, months, days, hours, minutes, and seconds, etc, but no attempt is made to keep this synchronized with the rotation of the earth - no leap seconds modifying the time stamps. A TAI calendar is an option. In that case the epoch time stamp would be TAI. But as I showed above, there are actually many different ways to get to fully metric elapsed time. I believe this is what we need to tell users about through a new calendar. We want them to know that the data producer is guaranteeing that the elapsed times in the time variable are fully metric. The particular time system used for the epoch date stamp is important, because you need to know what it is, but I don't see a strong motivation for TAI over UTC. If you, as a data producer, are messing with TAI, then I think it is reasonable to assume that you will have software that will convert to UTC. So if we back up a moment and stop considering which of many sources the data producer might have used to get her fully metric elapsed times, and if we take the simplifying approach of mandating UTC epoch time stamps, we see that all the different source cases fit in one new calendar. We don't need 4 (or 5 or 6) new calendars to account for the different possible sources for the fully metric elapsed times. -- 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-435980225
