Lots of good points here, but I think this _should_ be very simple: >> The CF explanation of the calendar attribute is
>> In order to calculate a new date and time given a base date, base time and a >> time increment one must know what calendar to use. For this purpose we >> recommend that the calendar be specified by the attribute calendar which is >> assigned to the time coordinate variable. The fact is that UTC and TIA are slightly different calendars -- as such users absolutely need to be able to specify which one is appropriate. Done. So this proposal is a great (maybe theo ly, really) compromise be the specification we need and backward compatibility. I am a bit confused by this, though: gregorian_utc - <snip> the time values may not be fully metric. huh? not entirely sure what "fully metric" means, but if, you have e.g.: seconds since 1980-01-01T12:00:00 the the actually values in the array should fully represent monotonically increasing values, and time[i] - time[j-i] should always represent exactly the number of seconds that has elapsed. what is non-metric about that??? BTW, this all is a really good reason to encode time in this way, rather than, say ISO datetime strings.... -CHB -- 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-434076182
