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

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



Hi John:

We think this problem is fixed in TDS 4.3. However, the server will have to 
upgrade to it, so that may take some time still, as 4.3 is not yet stable 
release.

Im closing this ticket but if you see an indication that its not correct in 
4.3, let us know.

John

> Ok heres what i understand so far:
> 
> 1. The problem is really the difference between java.util.Date and 
> org.joda.time.DateTime. TDS 4.3 is switching to joda time so that should get 
> fixed, as soon as I track down the 366 places where Im using Date ;^(
> 
> 2. The WMS server should be internally consistent with the set of dates it 
> puts out in its getCapabilities, and the ones that it accepts in its getMap 
> requests. You cannot use the dates from OPeNDAP to make a request from WMS.
> 
> 3. Im not really sure what special handling is expected of a reference date 
> of 000-01-01. As with much of the time handling in CF, its not well thought 
> out. Shouldnt there be a calendar attribute on the time coordinate?
> 
> > Hi THREDDS Support,
> > Thanks for the follow-up. Nope, they don't fall at the start of each month,
> > so that's not my concern. I just want them to match up with the dates that
> > WMS (TDS > ncWMS) is giving me. Since they don't match up, I have no way of
> > using the dates from one service to access the data/images from the other.
> > Here's a comparison of the two:
> >
> > 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
> >
> > Links for each of the above so you can see for yourself:
> >
> > a csv dump from NCSS:
> > http://oceanwatch.pifsc.noaa.gov/thredds/ncss/grid/climatologies/PF5_SST_Climatology_Monthly_1985_2001.nc?var=sst&latitude=21&longitude=-161&temporal=all&time_start=0001-01-16T06%3A00%3A00Z&time_end=0001-12-16T01%3A20%3A05Z&time=0001-01-16T06%3A00%3A00Z&vertCoord=&accept=csv&point=true
> >
> > see Dimension "time" in WMS GetCapabilities:
> > http://oceanwatch.pifsc.noaa.gov/thredds/wms/climatologies/PF5_SST_Climatology_Monthly_1985_2001.nc?service=WMS&version=1.3.0&request=GetCapabilities
> >
> > So, it could be a "problem" with either TDS/udunits or ncWMS. Either way, I
> > would like to see them match up so I don't have to hard-code a look-up
> > table. Thanks for listening.
> > Cheers,
> > John
> >
> > address@hidden> wrote:
> >
> > > Hi John:
> > >
> > > im seeing this coordinate:
> > >
> > >   double TIME(TIME=12);
> > >     :units = "hour since 0000-01-01 00:00:00";
> > >     :time_origin = "1-JAN-0000 00:00:00";
> > >     :modulo = " ";
> > >
> > > the values are:
> > >
> > > hour since 0000-01-01 00:00:00
> > > TIME =
> > >  {366.0, 1096.485, 1826.97, 2557.455, 3287.94, 4018.425, 4748.91, 
> > > 5479.395,
> > > 6209.88, 6940.365, 7670.85, 8401.335}
> > >
> > > giving dates:
> > >
> > >  0001-01-01 00:45:27Z
> > >  0001-01-31 11:14:33Z
> > >  0001-03-01 21:43:39Z
> > >  0001-04-01 08:12:45Z
> > >  0001-05-01 18:41:51Z
> > >  0001-06-01 05:10:57Z
> > >  0001-07-01 15:40:02Z
> > >  0001-08-01 02:09:09Z
> > >  0001-08-31 12:38:15Z
> > >  0001-09-30 23:07:21Z
> > >  0001-10-31 09:36:27Z
> > >  0001-11-30 20:05:33Z
> > >  0001-12-31 06:34:38Z
> > >
> > > presumably you really want these to be the start of each month ?
> > >
> > > > Hi TDS and UDUNITS Folks,
> > > > Just noticed the following bug: for monthly climatologies where the year
> > > is
> > > > set to "0000", NetCDF Subset Service (NCSS) is erroneously showing a 
> > > > year
> > > of
> > > > 0001. Here's the result of an AVHRR SST monthly climatology in NCSS:
> > > >
> > > >
> > > http://oceanwatch.pifsc.noaa.gov/thredds/ncss/grid/climatologies/PF5_SST_Climatology_Monthly_1985_2001.nc?var=sst&latitude=21&longitude=-161&temporal=all&time_start=0001-01-16T06%3A00%3A00Z&time_end=0001-12-16T01%3A20%3A05Z&time=0001-01-16T06%3A00%3A00Z&vertCoord=&accept=csv&point=true
> > > >
> > > > date,lat[unit="degrees_north"],lon[unit="degrees_east"],sst[unit="degrees
> > > > Celsius"]
> > > > 0001-01-16T06:00:00Z,21.0,-161.0,24.6
> > > > 0001-02-15T16:29:05Z,21.0,-161.0,24.45
> > > > 0001-03-17T02:58:12Z,21.0,-161.0,24.375
> > > > 0001-04-16T13:27:18Z,21.0,-161.0,24.45
> > > > 0001-05-16T23:56:24Z,21.0,-161.0,25.125
> > > > 0001-06-16T10:25:30Z,21.0,-161.0,25.875
> > > > 0001-07-16T20:54:36Z,21.0,-161.0,26.475
> > > > 0001-08-16T07:23:42Z,21.0,-161.0,27.0
> > > > 0001-09-15T17:52:48Z,21.0,-161.0,27.225
> > > > 0001-10-16T04:21:54Z,21.0,-161.0,27.15
> > > > 0001-11-15T14:51:00Z,21.0,-161.0,26.325
> > > > 0001-12-16T01:20:05Z,21.0,-161.0,25.2
> > > >
> > > >
> > > > If you list the time variable with OPeNDAP, you get the following
> > > > (units = "hour since 0000-01-01 00:00:00"):
> > > >
> > > >
> > > http://oceanwatch.pifsc.noaa.gov/thredds/dodsC/climatologies/PF5_SST_Climatology_Monthly_1985_2001.nc.ascii?TIME[0:1:11]
> > > >
> > > > Dataset {
> > > > Float64 TIME[TIME = 12];
> > > > } climatologies/PF5_SST_Climatology_Monthly_1985_2001.nc;
> > > > ---------------------------------------------
> > > > TIME[12]
> > > > 366.0, 1096.485, 1826.97, 2557.455, 3287.94, 4018.425, 4748.91,
> > > > 5479.395, 6209.88, 6940.365, 7670.85, 8401.335
> > > >
> > > >
> > > > Running the above numbers through udunits, it seems the problem is
> > > actually
> > > > with udunits:
> > > >
> > > >
> > > > > udunits
> > > > You have: 366 hour since 0000-01-01 00:00:00
> > > > You want:
> > > > Definition: "1317600 seconds since 1-01-01 00:00:00.00 UTC"
> > > > "366 hour since 0000-01-01 00:00:00" is 1-01-16 06:00:0 UTC
> > > >
> > > >
> > > > It lists the year simply as "1". In contrast, ncWMS/Godiva2 correctly
> > > > identifies the dates as belonging to year 0000:
> > > >
> > > >
> > > http://oceanwatch.pifsc.noaa.gov/thredds/godiva2/godiva2.html?server=http://oceanwatch.pifsc.noaa.gov/thredds/wms/climatologies/PF5_SST_Climatology_Monthly_1985_2001.nc
> > > >
> > > > Thanks for your attention to this detail. A further note of interest is
> > > that
> > > > NCSS does not handle milliseconds, so in my application I'm having to
> > > round
> > > > to seconds and hope I get a result.
> > > > Cheers,
> > > > John Maurer
> > > > Pacific Islands Ocean Observing System (PacIOOS)
> > > > University of Hawaii at Manoa
> > > >
> > > >
> > >
> > >
> > > Ticket Details
> > > ===================
> > > Ticket ID: PQT-331819
> > > Department: Support THREDDS
> > > Priority: Normal
> > > Status: Open
> > >
> > >
> >
> >
> 


Ticket Details
===================
Ticket ID: PQT-331819
Department: Support THREDDS
Priority: Normal
Status: Closed