Hi Seth,
> I'm confused by 1). Could you explain further?
A non-real-world calendar has no well-defined relationship to UTC. So CF must not refer to UTC in the definition of time zones for non-real-world calendars.
I proposed banning time zones as the "simplest" solution to this issue. If no one wants time zones in non-real-world calendars then there's some work software tool implementers (such as myself) can avoid.
But if time zones in non-real-world calendars are desirable (as you say they are) and can be described with a suitable definition then I've no objection to including them. I don't mind doing work, it's just unnecessary work I object to. ;-)
> Regardless, if there's no offset specified, the time coordinate
> still needs to be pinned down by having it be relative to some
> particular point on the globe.
That makes sense.
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: Seth McGinnis [mailto:mcginnis at ucar.edu]
Sent: 02 July 2013 20:51
To: Hattersley, Richard; cf-metadata at cgd.ucar.edu
Subject: Re: [CF-metadata] Non-real-world calendars
Hi Richard,
I'm confused by 1). Could you explain further?
It sounds like what you mean is that you want to propose that the basetime specified by the units attribute should not have an offset specifier after the date-time if the calendar is not real-world.
That makes sense, although I don't think I would support it. In regional climate modeling, people are concerned about things like the diurnal cycle, so there are cases where it would be convenient to define the base time such that the day boundaries align with local midnight. (We didn't do that in NARCCAP, but we did consider it as an option.)
Regardless, if there's no offset specified, the time coordinate still needs to be pinned down by having it be relative to some particular point on the globe. If you feel the need to make a distinction between UTC in real-world calendars and the logical equivalent (GMT, I suppose) in non-real-world calendars, that's fine, but I would say to do so very carefully; I think it would cause more confusion than it would clear up to just say that the statement in section 4.4 doesn't apply to non-real-world calendars...
Cheers,
--Seth
On Mon, 1 Jul 2013 13:26:22 +0000
"Hattersley, Richard" <richard.hattersley at metoffice.gov.uk> wrote:
>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".
>
>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<http://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<mailto:richard.hattersley at metoffice
>.gov.uk>
> Web: www.metoffice.gov.uk<http://www.metoffice.gov.uk/>
>
Received on Wed Jul 03 2013 - 08:03:08 BST
