[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: Mon, 28 Feb 2005 10:11:22 -0700
Christine,

>Date: Fri, 25 Feb 2005 14:10:11 -0600
>From: Christine Molling <address@hidden>
>Organization: UCAR/Unidata
>To: Steve Emmerson <address@hidden>,
>To: Tom Whittaker <address@hidden>
>Subject: Re: [Fwd: Re: [Fwd: UTM file]]

The above message contained the following:

> What am I trying to accomplish?  Merely express time in units that have 
> a one-to-one relationship with calendar time.

Good luck.  Units of the physical quantity "time" don't have a simple,
one-to-one relationship with calendar time.  Believe me, I've beaten 
my head against this issure more times than I can remember.

> I'm developing precision 
> agriculture software in which events happen on specific days (I use days 
> since yyyy-mm-dd), and in which some quantities may only be applicable 
> to a year, such as yield, or accumulated drainage.  For those I use 
> 'year', because the quantity is not associated with any one particular 
> day.  I can forsee some situation where two different persons get some 
> model output and their converted values are different because of the 
> average vs exact number of days per year issue.
> 
> I understand that the Udunits folks might not want to tackle converting 
> our "strange" calendar's years or months to days.

Right.  That's outside the scope of the UDUNITS package, which was
designed to handle units of physical quantities only.

> Although now that I 
> think about it, doesn't everybody (at least in the Atmos Sci community) 
> have that same data table of number-of-days-per-month in at least one of 
> their programs?  Unless there is concern about code bloat in Udunits, 
> why not stick calendar conversions in there for commonly used calendars?
> Everyone would love to have it in there, I'm sure.

No doubt.  Unfortunately, it's non-trivial, would easily double the size
of the package, doesn't have any standards, and would consume time I
don't have.

What we need is a freely-available calendar package for C and Fortran.
If you know of one, then use it and let me know about it.

Regards,
Steve Emmerson