NOTICE: This version of the NSF Unidata web site (archive.unidata.ucar.edu) is no longer being updated.
Current content can be found at unidata.ucar.edu.
To learn about what's going on, see About the Archive Site.
NOTICE: This version of the NSF Unidata web site (archive.unidata.ucar.edu) is no longer being updated.
Current content can be found at unidata.ucar.edu.
To learn about what's going on, see About the Archive Site.
Hi all:I assume that someone who uses "months" really wants "calendar months", which manipulates the calendar fields, rather than using a fixed duration in seconds. The CDM implements this :
http://www.unidata.ucar.edu/software/netcdf-java/CDM/CalendarDateTime.html and i think i still have to make a formal proposal to CF for it.However, concerns about backwards compatibility have scuttled most attempts to extend datetime handling in CF.
John On 4/10/2013 11:59 PM, Signell, Richard wrote:
Patrick, Lansing & Co: I note that the time units for this dataset are: "units: months since 1901-01-01 00:00:00" with "calendar: standard" In the CF documentation http://cf-pcmdi.llnl.gov/documents/cf-conventions/1.6/ch04s04.html it warns about units of "month": " We recommend that the unit year be used with caution. The Udunits package defines a year to be exactly 365.242198781 days (the interval between 2 successive passages of the sun through vernal equinox). It is not a calendar year. Udunits includes the following definitions for years: a common_year is 365 days, a leap_year is 366 days, a Julian_year is 365.25 days, and a Gregorian_year is 365.2425 days. For similar reasons the unit month, which is defined in udunits.dat to be exactly year/12, should also be used with caution." Perhaps the WMS and OPeNDAP service are not handling units of month in the same way? -Rich On Wed, Apr 10, 2013 at 5:45 PM, Lansing Madry <madry@xxxxxxxxxxxxxxxx> wrote:Hi Patrick, I pulled down the file via http service and looked at it in ToolsUI. ToolsUI (perhaps unsurprisingly) gives the "1951-07-16T12:12:04.339Z" value. I'm not familiar with ferret as an OpenDAP client or viewer, have you heard from anyone on that front? Regards, Lansing Madry Unidata Boulder, Colorado On 4/9/2013 11:08 AM, Patrick Brockmann wrote:Hi all, I have a strange behaviour with time dimension values exposed by the GetCapabilities and values get from an OPeNDAP access. Could someone explain me what is the source of the problem ? http://webportals.ipsl.jussieu.fr/thredds/wms/CARBON/CARBONES_PRIOR_orchidee_hadgem2-es_historical_nosoc_co2_npp_monthly_1951_2004_yearmonmean_3.nc?service=WMS&version=1.3.0&request=GetCapabilities ---> 1951-07-16T12:12:04.339Z, .... And from the OPeNDAP access with ferret client, I get ferret yes? use "http://webportals.ipsl.jussieu.fr/thredds/dodsC/CARBON/CARBONES_PRIOR_orchidee_hadgem2-es_historical_nosoc_co2_npp_monthly_1951_2004_yearmonmean_3.nc"; yes? sg/t/l=1:10 npp2 GRID GTL2 name axis # pts start end MYLON LONGITUDE 720mr 0E 0.5W LAT LATITUDE 360 r 89.75S 89.75N normal Z TIME TIME 54 r 16-JUL-1951 12:33 15-JUL-2004 09:01 L T TBOX TBOXLO TSTEP (months) 1> 16-JUL-1951 12:33:59 12 14-JAN-1951 21:39:23 606.4526 2> 15-JUL-1952 18:23:11 12 15-JAN-1952 03:28:35 618.4526 3> 16-JUL-1953 00:12:23 12 14-JAN-1953 09:17:47 630.4526 --> Note the difference between 1951-07-16T12:12:04.339Z and 16-JUL-1951 12:33:59 My TDS version is Version 4.3.15 - 20121218.1126 Regards Patrick_______________________________________________ thredds mailing list thredds@xxxxxxxxxxxxxxxx For list information or to unsubscribe, visit: http://www.unidata.ucar.edu/mailing_lists/
thredds archives: