[CF-metadata] Non-real-world calendars

From: Jonathan Gregory <j.m.gregory>
Date: Wed, 3 Jul 2013 15:12:54 +0100

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?
>
> 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.

Yes, I appreciate that, but I think some of the points are in common.

Year 0 is problematic in the real-world calendars, because it doesn't exist
and yet is allowed by udunits. Year 0 is OK in the non-real-world calendars.
Hence the clarification required only applies to the real-world calendars.

> 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.

At the end of that ticket, I suggested the best solution would be disallow year
and month as units in CF, in any calendar. That may agree with what you think.

> > 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.

I don't see a problem with UTC, because I think it is natural to interpret it
as the time at longitude zero. That's how model time is usually interpreted. I
can't see a difficulty with fixed offsets wrt UTC, except for daylight-saving,
and offsets might be useful in some applications.

Best wishes

Jonathan
Received on Wed Jul 03 2013 - 08:12:54 BST