For what's it's worth, my thoughts on how to classify real-world vs. non-real-world ...
Start by defining a calendar as a way to label a continuous time axis. Then a real-world calendar is one where there is a unique bijection from the calendar's time axis to time in the real world (roughly equivalent to the existence of a well-defined relationship to TAI).
A 360-day calendar has no such relationship, so should be classified as a non-real-world calendar. For example, one might choose to associated 2013-01-01 on a 360-day calendar with 2013-01-01 in the Gregorian calendar. But what does 2013-02-30 in the 360-day calendar associated with in the Gregorian calendar? And what does 2013-01-31 in the Gregorian calendar associated with in the 360-day calendar?
NB. If anyone mentions Einstein/relativity at this point I shall get cross! ;-)
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
-----Original Message-----
From: CF-metadata [mailto:cf-metadata-bounces at cgd.ucar.edu] On Behalf Of Hattersley, Richard
Sent: 03 July 2013 13:28
To: 'Ansley Manke'; cf-metadata at cgd.ucar.edu
Subject: Re: [CF-metadata] Fwd: Non-real-world calendars
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/>
_______________________________________________
CF-metadata mailing list
CF-metadata at cgd.ucar.edu
http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
Received on Wed Jul 03 2013 - 07:07:27 BST
