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
NOTE: All email exchanges with Unidata User Support are recorded in the Unidata inquiry tracking system and then made publicly available through the web. If you do not want to have your interactions made available in this way, you must let us know in each email you send to us.