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

[THREDDS #YJM-623796]: NetCDF Subset Service (NCSS) and UDUNITS: wrong datetimes for climatologies

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: [THREDDS #YJM-623796]: NetCDF Subset Service (NCSS) and UDUNITS: wrong datetimes for climatologies
  • Date: Fri, 08 Jul 2011 10:15:42 -0600
John,

> Although the Wikipedia article was good reading, here are quotes from
> something more à propos (the CF
> Conventions<http://cf-pcmdi.llnl.gov/documents/cf-conventions/1.5/cf-conventions.html>
> ):
> 
> "A reference time in year 0 has a special meaning (see Section 7.4,
> “Climatological
> Statistics”<http://cf-pcmdi.llnl.gov/documents/cf-conventions/1.5/cf-conventions.html#climatological-statistics>
> )."
> 
> "For compatibility with COARDS, time coordinates should also be recognised
> as climatological if they have a units attribute of time-units relative to
> midnight on 1 January in year 0 i.e. since 0-1-1 in udunits syntax , and
> provided they refer to the real-world calendar."
> 
> So there is a year 0 afterall: a convention used in the earth science
> community to designate a climatology. They were even detailed enough to
> suggest that "since 0-1-1" should work in your software, but that seems to
> be a false claim since it returns "since 1-01-01". Anyways, I'm working with
> an external data source: I don't have control over how they designate their
> year.

Unfortunately, the conventions you quote were adopted years after the UDUNITS 
API was defined. As a consequence, applications have to be written so that they 
handle the additional semantics rather than leaving it all to the UDUNITS 
package. The best way to do that is to use one of the many calendaring packages 
that are out there rather than rely on the overly simplistic calendar-handling 
of the UDUNITS package.

> A bigger concern is the time returned by udunits. If it was a simple
> substitution of year 1 for year 0, that would be an easy workaround.
> However, I also get different days and times than what WMS is advertising
> from TDS.
> 
> TDS/NCSS/UDUNITS (left) vs. TDS WMS/ncWMS (right):
> 
> 0001-01-16T06:00:00Z, 0000-01-14T06:00:00.000Z
> 0001-02-15T16:29:05Z, 0000-02-13T16:29:05.999Z
> 0001-03-17T02:58:12Z, 0000-03-15T02:58:12.000Z
> 0001-04-16T13:27:18Z, 0000-04-14T13:27:18.000Z
> 0001-05-16T23:56:24Z, 0000-05-14T23:56:24.000Z
> 0001-06-16T10:25:30Z, 0000-06-14T10:25:30.000Z
> 0001-07-16T20:54:36Z, 0000-07-14T20:54:36.000Z
> 0001-08-16T07:23:42Z, 0000-08-14T07:23:42.000Z
> 0001-09-15T17:52:48Z, 0000-09-13T17:52:48.000Z
> 0001-10-16T04:21:54Z, 0000-10-14T04:21:54.000Z
> 0001-11-15T14:51:00Z, 0000-11-13T14:51:00.000Z
> 0001-12-16T01:20:05Z, 0000-12-14T01:20:05.999Z
>
> What gives?

I'm afraid that I don't know enough about TDS/NCSS/WMS/ncWMS to understand the 
problem. I'll consult with someone who should.

> Thanks,
> John

Regards,
Steve Emmerson

Ticket Details
===================
Ticket ID: YJM-623796
Department: Support UDUNITS
Priority: Normal
Status: Closed