Breaking these down into manageable chunks ... > ... we allow a construction in which 2 minutes since 2016-12-31 23:59:00 to > be 0 minutes since 2017-01-01 00:01:00 and for these to be UTC times, so that > the length of the 2 minutes is 121 seconds. Consequently, any coordinate we > defined through this kind of construction would be, in your words, a > non-metric time.
Yeah, I can see that would be "non-metric" -- but why in the world would we want to allow that? and in fact, how could you allow that??? CF time encoding involves *one* datetimestamp, not two. It would be a really bad idea to somehow mix and match TIA and UTC in one time variable -- specify the timestamp in UTC, but that processing tools should use TIA from there on?? two minutes is never, ever, anything but 120 seconds. Let's not confuse what I am calling a timestamp -- i.e. the "label" for a point in time from a time duration. So: the duration between: 2016-12-31 23:59:00 and 2017-01-01 00:01:00 is 120 seconds in the UTC Calendar, and 121 seconds in the TIA calendar. so: 120 seconds since 2016-12-31 23:59:00 will be a different timestamp if you use the TIA calendar than if you use the UTC calendar -- just as it maybe be different if you use any other calendar.... So what is the problem here? Granted -- if you want to accurately create or use a tiem variable with the TIA calendar, you need a library that can do that -- but that is not CF's problem. -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/cf-convention/cf-conventions/issues/148#issuecomment-434377915
