It seems this issue has become a bit entangled with multiple problems in search
of a solution— they are all related to calendars, but also could each be
independently implemented. Maybe separate issue for each?
In the meantime, I think these are what’s on the table:
- calendar(s) used for climate modeling — 360 days per year.
- proposed solution: we come up with a name and definition and we’re done.
- question: do climate modelers use “time stamps” that look like the
Gregorian calendar? That is: March 15, 2025? (And of course, potentially
February 30, 2100)? If so then this is all pretty straightforward. If, on the
other hand, they use another system, like year 2025, day 154. Then we should
have a way to directly encode that.
- is there any ambiguity in what “2016-06-15” means? Does anyone care about
that ambiguity? That is, saying a timestamp is UTC clearly identifies it, but
what does a timestamp in 360_day_year calendar mean? Can it be converted to UTC?
OK, that’s enough for a phone...
--
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-435435361
