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.
Mary, > We have been using udunits' utCalendar function in NCL code for some > time now, and it's a popular function. > > We get frequent requests for calendars other than the ones supported > by udunits, like "noleap", > "360 day", and "365 day". The ability to offset the origin of a unit was added to the UDUNITS package in order to accomodate units such as Fahrenheit and Celsius. This was done in a generic way, and so automatically included temporal units. Allowing that capability for non-temperature units was a big mistake. People are using that capability to kluge support for physical quantities in a way that lies completely outside the domain of units for physical quantities. A much better solution would be to create a library that supported co-ordinate transformations of physical quantities directly, rather than through kluges on their units. Adding support for non-Earth calendars would be adding a kluge on top of bad existing kluge. I understand your concern, but this is *not* the way to go. A far better solution would be to use a calendar-conversion library, a netCDF attribute that specified the calendar system, and not use the "since" capability of the UDUNITS package. > David Pierce, the developer of ncview has created his own version of > utCalendar that adds the above calendars to the ones that Udunits > already supports. > > Has there ever been a consideration for incorporating David's code > into Udunits? Regards, Steve Emmerson Ticket Details =================== Ticket ID: NMJ-986812 Department: Support UDUNITS Priority: High Status: Closed