Hi Ansley,
> > 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!?) ...
> For one thing, there should be a definition of "real world
> calendars", shouldn't there.
Sorry, but I'm not clear what you're referring to. Are you asking for a classification of CF calendars as real-world vs. non-real-world?
> > 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.
> For each calendar, there's a year length in days. The definition of
> "years-since", etc. would always flow from the calendar definition
> that's in place. So if the definition of time is noleap (equivalent
> to Udunits common_year), then years_since or days-since would be
> computed using a 365-day year. Is that what the Udunits library
> does?
Sadly, no. A "year" in UDUNITS-2 is just an alias for a "tropical year" of 365.242198781. days. And the only calendar UDUNITS-2 understands is the hybrid Gregorian/Julian. To quote the UDUNITS-2 documentation, "You should use a true calendar package rather than the UDUNITS-2 package to handle time."
> "Month" is inherently ambiguous as discussed in the CF document, but
> would be 1/12 of a year. In CF, the definition of a year as
> 365.242198781 days doesn't apply to any of the calendars, because it
> doesn't relate to calendar months/days/hours etc. (Does the Udunits
> library use that number? How?)
At the moment CF just defers to UDUNITS-2 for "month", which defines it as a twelfth of a tropical year. So as things currently stand, N "months since 1970-01-01" is equivalent to N x 30.436849898 days in *all* the CF calendars. I cannot think of a situation where this is desirable for a 360-day calendar.
So the current CF definition of "month" isn't ambiguous, it's quite precisely defined... it just has no practical use in a non-real-world calendar.
I would like to see the definition of a month explicitly excluded from non-real-world calendars, or re-defined to a calendar-specific value/semantic (perhaps via some alternative term such as "calendar_month").
The bottom line, since UDUNITS-2 quite clearly states one should look elsewhere for calendar handling, CF must not defer the definition of alternative calendars to UDUNITS-2!
Richard Hattersley
Benevolent Dictator of Iris - a CF library for Python: www.scitools.org.uk/iris
Met Office FitzRoy Road Exeter Devon EX1 3PB United Kingdom
Tel: +44 (0)1392 885702
Email: richard.hattersley at metoffice.gov.uk Web: www.metoffice.gov.uk <
http://www.metoffice.gov.uk/>
________________________________
From: Ansley Manke [mailto:ansley.b.manke at noaa.gov]
Sent: 02 July 2013 17:49
To: cf-metadata at cgd.ucar.edu
Cc: Hattersley, Richard
Subject: Re: Fwd: [CF-metadata] Non-real-world calendars
Hi Richard,
I have some opinions and discussion on some of your points.
On 7/1/2013 8:41 AM, Steve Hankin wrote:
Yo may want to follow/participate on this discussion
-------- Original Message --------
Subject: [CF-metadata] Non-real-world calendars
Date: Mon, 1 Jul 2013 13:26:22 +0000
From: Hattersley, Richard <richard.hattersley at metoffice.gov.uk> <mailto:richard.hattersley at metoffice.gov.uk>
To: cf-metadata at cgd.ucar.edu <cf-metadata at cgd.ucar.edu> <mailto:cf-metadata at cgd.ucar.edu>
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!?) ...
For one thing, there should be a definition of "real world calendars", shouldn't there.
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.
For each calendar, there's a year length in days. The definition of "years-since", etc. would always flow from the calendar definition that's in place. So if the definition of time is noleap (equivalent to Udunits common_year), then years_since or days-since would be computed using a 365-day year. Is that what the Udunits library does? "Month" is inherently ambiguous as discussed in the CF document, but would be 1/12 of a year. In CF, the definition of a year as 365.242198781 days doesn't apply to any of the calendars, because it doesn't relate to calendar months/days/hours etc. (Does the Udunits library use that number? How?)
All of the calendars in CF section 4.4.1 have definitions that allow software to convert between time coordinates and date-strings using the unit, time origin and calendar. They're consistent within themselves. Each one implies a number of days/fractional days per year.
Ansley
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".
I have some further questions concerning real-world calendars, but as with all things dealing with the real world they are a little more messy so I'll save them for another post.
Richard Hattersley
Benevolent Dictator of Iris - a CF library for Python: www.scitools.org.uk/iris
Met Office FitzRoy Road Exeter Devon EX1 3PB United Kingdom
Tel: +44 (0)1392 885702
Email: richard.hattersley at metoffice.gov.uk Web: www.metoffice.gov.uk <
http://www.metoffice.gov.uk/>
Received on Wed Jul 03 2013 - 06:28:23 BST
