[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Fwd: Re: [Fwd: UTM file]]
- Subject: Re: [Fwd: Re: [Fwd: UTM file]]
- Date: Wed, 23 Feb 2005 15:24:02 -0700
Christine,
> Subject: Re: [Fwd: UTM file]
> Date: Wed, 23 Feb 2005 09:38:36 -0600
> From: Christine Molling <address@hidden>
> Organization: UCAR/Unidata
> To: John Caron <address@hidden>
> CC: Tom Whittaker <address@hidden>
> References: <address@hidden>
The above message contained the following:
> Recently I have discovered that using units of years since a date does
> not parse correctly in some software that uses udunits (I'm referring to
> ncview here). So now I have just changed the units to either "year" or
> "days since yyyy-mm-dd". However, the "year" unit is problematic,
> because if you look at the various versions of year...
>
> tropical_year P 3.15569259747e7 second
> lunar_month P 29.530589 day
> common_year P 365 day # exact: 3.153600e7 seconds
> leap_year P 366 day # exact
> Julian_year P 365.25 day # exact
> Gregorian_year P 365.2425 day # exact
> year P tropical_year
> yr P year
> a S year # "anno
>
> you will see that none of them describes a calendar year having a
> specific number of days that depends on the year (i.e. 365 vs 366).
A unit that varied according to the year would be a strange unit,
indeed.
> common_year and leap_year come closest, but you can't have both units
> for one variable - the unit changes depending on the year.
> Gregorian_year is the next closest to the correct definition, even
> though I would argue that the udunits definition is wrong, since the
> definition is actually an average. It is only "exact" once every 400
> years. Do you know of any fixes in the works for this, such as
> "calendar_year", with an attribute :calendar="Gregorian"? I suppose
> that's a question for the udunits folks. The same sort of problem
> occurs with months, but fortunately I don't have to worry about that one
> in my work (a similar "calendar_month" :calendar="Gregorian" would work
> there too).
Unfortunately, calendar operations are beyond the scope of the UDUNITS
package, which was designed to handle units of physical quantities and
not time in general. Consequently, a solution to this problem must come
from outside the UDUNITS package.
What is it that you are trying to accomplish?
Regards,
Steve Emmerson