⇐ ⇒

[CF-metadata] udunits time unit question

From: Seth McGinnis <mcginnis>
Date: Thu, 31 Mar 2011 11:18:49 -0600

For those who have never encountered a non-standard calendar in the wild,
here's one place they show up:

360-day and 365-day calendars are used in climate modeling. It requires a lot
of extra work to write code that can handle leap years by making the year
length variable, and the payoff for doing so is minimal. So in most (maybe
all) cases, nobody's ever done it. Even the irregularity of variable-length
months is too much work for some model developers.

Yes, 1960-01-31 is an illegal date in a 360-day calendar. The year 1960 would
generally mean "the year when prescribed model conditions correspond to the
real-world conditions of 1960". You wouldn't get a cumulative offset in the
dates using "years since" because there's no one-to-one mapping between model
days and historical days -- if you want to compare the model output with data
that uses a different calendar, the first thing you do is aggregate it to a
monthly or longer timescale where there is a one-to-one correspondence. (And
usually it doesn't make much sense to compare things day-by-day anyway.)

The point of storing the data using the 360-day calendar is that it faithfully
reflects the structure of the model output. You could massage the data to fit
a Gregorian calendar, but it would be extra work, it would introduce gaps in
the time coordinate, and the result might not accurately reflect the
descriptions of what went into the model. For example, if some land-cover
boundary condition was prescribed on a monthly basis, you'd infer the wrong
value for day 60 if the calendar was Gregorian (March 1st) instead of 360-day
(Feb. 30th). So it's just better all ways round to define a non-standard
calendar that matches how the model works.

Does that help clarify what's going on with these strange beasts?

Cheers,

--Seth

>360_day
> All years are 360 days divided into 30 day months.
>
>OK, so I take it that a day is 24 hours, so a year is 24 * 360 hours long. I
>can see the utility in this, but then i guess 1960-01-31 is illegal? And if
>you do "years since" or even "months since", the meaning is going to get very
>offset after a few year from the "usual" calendar.
>
>I'm also not sure what "1960-01-01" means in a 360_day calendar -- what is
>year 0? Or do you use the Gregorian calendar for the "point in time" part?
>Maybe that doesn't matter, as long as we aren't concerned about absolute
>dates. This does satisfy Steve's point about having a meaningful axis for
>doing math -- every month and year is the same length.
>
>However, at the end of the day, I don't see the use -- you really can't talk
>about dates in this calendar anyway, so why not pick an arbitrary point in
>time and use hours? When if comes down to it, I can certainly see why one
>might want to do calculations and plotting, etc, in those calendars, but I
>don't see why your netcdf file has to store the data that way.

-----
Seth McGinnis
NARCCAP Data Manager
Associate Scientist
IMAGe / NCAR
------
Received on Thu Mar 31 2011 - 11:18:49 BST

This archive was generated by hypermail 2.3.0 : Tue Sep 13 2022 - 23:02:41 BST

⇐ ⇒