Hi Jonathan,
Thanks for your feedback.
> 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.
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.
It is conceivable that the discussion on #101 could be extended further to include the non-real-world calendars, but I am wary of doing so because of the seemingly large "drag factor" that comes into play when discussing real-world calendars.
> 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.
Regards,
Richard
-----Original Message-----
From: CF-metadata [mailto:cf-metadata-bounces at cgd.ucar.edu] On Behalf Of Jonathan Gregory
Sent: 01 July 2013 18:17
To: cf-metadata at cgd.ucar.edu
Subject: [CF-metadata] Non-real-world calendars
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" <richard.hattersley at metoffice.gov.uk> -----
> From: "Hattersley, Richard" <richard.hattersley at metoffice.gov.uk>
> To: "cf-metadata at cgd.ucar.edu" <cf-metadata at cgd.ucar.edu>
> 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
CF-metadata at cgd.ucar.edu
http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
Received on Tue Jul 02 2013 - 04:50:34 BST
