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? I would not be surprised if point 1 has been raised somewhere, but I can't remember! Is this exclusion really necessary? 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? An hour is a well-defined unit. 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.
Best wishes Jonathan ----- Forwarded message from "Hattersley, Richard" <[email protected]> ----- > From: "Hattersley, Richard" <[email protected]> > To: "[email protected]" <[email protected]> > Date: Mon, 1 Jul 2013 13:26:22 +0000 > Subject: [CF-metadata] Non-real-world calendars > > Hi everyone, > > I'd like to propose a trac ticket or two to clarify the meaning when using > alternative calendars. But before I do that I'd like to check for community > opinion (or even consensus!?) ... > > 1. Time zones should be excluded/banned when using non-real-world calendars. > For example, the statement in section 4.4 of "if the time zone is omitted the > default is UTC" should not apply. > > 2. The "months since" and "years since" semantics for non-real-world > calendars need defining/outlawing. e.g. The UDUNITS definition of a year as > 365.242198781 days makes no sense at all for a 360-day calendar, but in this > particular case a year could be unambiguously defined as 360 days. > > 3. The year-zero semantics for non-real-world calendars need defining. From > section 7.4, "Year 0 may be a valid year in non-real-world calendars". _______________________________________________ CF-metadata mailing list [email protected] http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
