Dear Richard > > Issues like these have been raised before, and in fact there are two > > open tickets (96 and 101) which I think relate to your points 2 and > > 3. Perhaps you could have a look at them? > > In the hope of making progress my statements/questions are deliberately > confined to non-real-world calendars, whereas ticket 96 is exclusively > concerned with the "real-world" mixed Gregorian/Julian calendar.
Yes, I appreciate that, but I think some of the points are in common. Year 0 is problematic in the real-world calendars, because it doesn't exist and yet is allowed by udunits. Year 0 is OK in the non-real-world calendars. Hence the clarification required only applies to the real-world calendars. > Ticket 101 was proposed as a correction for the definition of "year" within > the Julian/Gregorian calendar. But the correction is not actually required, > so the discussion has moved on to consider what meaning, if any, should be > allowed for "year" in the Gregorian/Julian calendar. At the end of that ticket, I suggested the best solution would be disallow year and month as units in CF, in any calendar. That may agree with what you think. > > Time-zones probably aren't needed for non-real-world calendars, > > which are typically used in climate models only - but do they do any > > harm, if they are simply defined as offsets in hours? > > Yes - I think they do harm. I suspect (hence the posting) they are not used. > Yet they introduce ambiguity of interpretation, and they require effort to > support in software. Both of which cost time (no pun intended) and money. > > > Perhaps the argument would be that time-zones involve summer time > > (daylight- saving), and in the non-real-world calendar it wouldn't > > be clear when summer time applies. > > That's a good example. For another, consider that the conventions define time > zones with respect to UTC. But a non-real-world calendar has no defined link > to UTC so there's confusion right from the start. I don't see a problem with UTC, because I think it is natural to interpret it as the time at longitude zero. That's how model time is usually interpreted. I can't see a difficulty with fixed offsets wrt UTC, except for daylight-saving, and offsets might be useful in some applications. Best wishes Jonathan _______________________________________________ CF-metadata mailing list [email protected] http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
