[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Fwd: Re: [Fwd: UTM file]]

This archive contains answers to questions sent to Unidata support through mid-2025. Note that the archive is no longer being updated. We provide the archive for reference; many of the answers presented here remain technically correct, even if somewhat outdated. For the most up-to-date information on the use of NSF Unidata software and data services, please consult the Software Documentation first.

  • 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